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POLICY - PASCAL USER'S GROUP and PASCAL NEWSLETTER 



USER'S GROUP POLICIES 



Purposes 



are to promote the use of the programming language Pascal as well as the 
ideas behind Pascal. Pascal is a practical language with a small , systematic 
and general purpose structure being used for: 



Membership 



* teaching programming concepts 

* developing reliable "production 



software 
implementing software efficiently on today's machines 
* writing portable software 

is open to anyone: particularly the Pascal user, teacher, maintainer, 
implementor, distributor, or just plain fan. Institutional memberships, 
especially libraries, are encouraged. Membership is per academic year ending 
June 30. Anyone joining for a particular year will receive all 4 quarterly 
issues of ?<u cat Af m&t zttvi for that year. (In other words, back issues are 
sent automatically. ) First time members receive a receipt for membership; 
renewers do not to save PUG postage. 

Cost of membership per academic year is $4 and may be sent to: 

Pascal User's Group/ %Andy Mi ckel /University Computer Center/ University of 

Minnesota/Minneapolis, MN 55455 USA/ phone: (612) 376-7290 

In the United Kingdom, send £2.50 to: 

Pascal Users' Group/ %Judy Mull ins/Mathematics Department/The University/ 

S0UTHAMPT0N/S09 5NH/United Kingdom/ (telephone 0703-559122 x2387) 



NEWSLETTER POLICIES 



>- 
o 
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The Pcucal Uzmlzttvi the official but informal publication of the User's Group. It 
is produced quarterly (usually September, November, February, and May). A 
complete membership list is printed in the November issue. Single back 
issues are available for $1 each. Out of print: #s 1,2,3 
#4 available from George Richmond/Computing Center/U of Colorado/Boulder/80309 

The contribution by PUG members of ideas, queries, articles, letters, and opinions for 
the Hm&loXtoA is important. Articles and notices concern: Pascal 
philosophy, the use of Pascal as a teaching tool, uses of Pascal at different 
computer installations, portable (applications) program exchange, how to 
promote Pascal usage, and important events (meetings, publications, etc.). 

Implementation information for the programming language Pascal on different computer 

systems is provided in the Um&l&ttQA out of the necessity to spread the use 
of Pascal. This includes contacts for maintainers, documentors, and 
distributors of a given implementation as well as where to send bug reports. 
Both qualitative and quantitative descriptions for a given implementation are 
publicized. Proposed extensions to Standard Pascal for users of a given . 
implementation are aired. Announcements are made of the availability of new 
program writing tools for a Pascal environment. 

Miscellaneous features include bibliographies, questionaires, and membership lists. 
Editor's notes are in Pascal style comments (**). 

WRITTEN INFORMATION FOR THE HamltLttin. is EASIER TO PRINT IF YOU TYPE 
ALL MATERIAL Vi OR DOUBLE SPACED SO THAT IT IS IN "CAMERA-READY" AND 
PHOTO-REDUCIBLE FORM FOR THE PRINTER. REMEMBER, ALL LETTERS TO US WILL 

UNLESS THEY CONTAIN A REQUEST TO THE CONTRARY, 
AN OLD MAP MAGAZINE APPLIES: " all thd nom that 
John P. Strait, associate editor. Nov. 10, 1976. 
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UNIVERSITY OF MINNESOTA 

TWIN CITIES 



University Computer Center 

227 Experimental Engineering Building 

Minneapolis, Minnesota 55455 

(612) 376-7290 



PART I - Standards 

yow! It took only one issue of PUG's Pascal Newsletter to bring on an avalanche 
% of "Where do we go from here?"s! It was first put clearly in print with a short note 
in PUGN #3 by George Poonen who noted that various implementations had diverged and 
that a standard was necessary. Now we have: Tony Addyman, Frank Brewster, Charles 
Hedrick, and Willett Kemp ton (see News in HERE AND THERE); Mike Schneider, Rich 
Cichelli, and Arthur Sale (see ARTICLES); and Steve Young, Tony Addyman (again), 
Duke Haiduk, Judy Mull ins, Arthur Sale (again), and Tim Bonham (see OPEN FORUM) all 
discussing the topic of standards. The concern, I believe, is out of our desire to 
see Pascal succeed. We are in a computing environment which is not altogether 
friendly to Pascal. We want to be able to respectably use Pascal in the future. 

I have been very confused on the subject of Pascal standards in the past. Mike 
Schneider and Rich Cichelli have (I think) straightened me out. You see, I thought 
we already had a Standard Pascal, with the Revised Report and the Axiomatic 
Definition. These two concise and elegant (although not perfect - but yet what do you 
want?) documents were produced by Niklaus Wirth and his associates and coworkers. 
And I believe that Pascal has merit because it was produced by a single man of the 
calibre of Niklaus Wirth, who (as evident from his work) profoundly understands 
programming language design, from linguistics to implementation. This one person 
could decide what to meld when meeting al_l_ of the design goals set out from the start. 

I wanted to do what I could to call for adherence to what Niklaus Wirth called 
"Standard Pascal". Because with time, I increasingly appreciated what he had written 
in several articles. He pointed out for example that certain "favorite features" had 
to be omitted in order to meet the design goals of a small and efficient system. Also 
that some aspects were best left undefined. And that other features were omitted with 
good reason to achieve the goal of providing a tool with which to produce reliable 
software (okay - you could call it: "protect the error-prone human programmer from 
himself or herself." It may not be pleasant, but experiencing is believing; a good 
dose of egoless programming goes well with this.) It goes without saying that Pascal 
is not the ultimate programming language, or perfect, or that it is all things to all 
people. All good so far. 

EDITOR'S CONTRIBUTION 



But then other events took place. The Revised Report suffered "revisionism": 
Nov., 1972, July, 1973, Dec, 1973, the User Manual and Report, first edition (1974), 
second edition, first printing (1975), and now the second edition, third printing (1976). 
How can one calljfor adherence to the "standard" when the same(?) "standard" keeps 
changing? 

Also among the many ill-conceived suggestions for "improvements" to the language 
by users, there were some very few that seemed reasonable to dyed-in-the-wool Pascal ers. 
There was no mechanism for sounding these out for worthiness and acceptance, save 
writing to Niklaus and Urs in Zurich. This has been \/ery frustrating because we didn't 
know where we were heading. (What was Pascal's future destined to be according to its 
creators?) We were told on the one hand, "no more changes." We relaxed and said 
"fine." Then a revision came along and we felt cheated. We weren't kept informed 
of what other users had suggested, either. 

Rich and Mike have pointed out that Pascal can't continue to be what Niklaus 
Wirth says it is. And that Andy Mickel can't arbitrarily restrain attempts to change 
it because 1) Andy fears destruction of the language by attempts to "save" it, or 
2) Andy doesn't want them to destroy the essential simplicity of Pascal which is 
probably its most likely reason for success. They also pointed out that we don't have 
an officially accepted standard ; a "political standard" if you will. Really, when 
that concept dawned on me it made sense. A major computer manufacturer, when choosing 
a common language for all its software development, democratically decided to pick the 
one that most of its programmers wanted to use. With the choice of language X 30%, 
Pascal version A 25%, Pascal version B 13%, and Pascal version C 27%, language X won 
by a plurality (and by default!) and too "bad - as we all can see. If we want Pascal 
to ultimately and completely succeed, we can't have this! 

Now how do we resolve the conflict(s)? Many persons suggest a "PUG Standards 
Committee", and frankly, although I think committees are inherently evil, I don't see 
any other choice. The alternative at this point is to lower our expectations, quit 
striving for excellence, quit "dreaming the impossible dream" of seeing Pascal take 
over the majority of industrial and academic computing (wiping out Cobol and Fortran 
within our lifetimes). Then we could say regretfully - "wow, Pascal's nice, but..." 
as so many of our half-hearted supporters and critics do now. 

I feel that: 1) we should continue to debate this topic; 2) a PUG Standards 
Committee when set up should be small (less than 8 members); 3) its charter be 
initially agreed on so as to limit its power; 4) within the committee's initial charge 

* This brings to mind two acronyms: John Easton's SHAFT or Society to Help Abolish 
Fortran Teaching, and Mitch Wand's ACS or the American Cobol Society - analogous 
in meaning to the American Cancer Society. 
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EDITOR'S CONTRIBUTION 



the action should be to get the Revised Report ( User Manual and Report , Second Edition 
third printing) accepted as an official standard as is (even if only provisionally); 
5) later the committee could recommend subsequent actions. 

Look up the articles in this issue of PUG Newsletter by Mike and Rich with their 
excellent analyses of the current situation. Rich bluntly hints that many features are 
best left to separate software writing tools. In all honesty, I don't see how Arthur 
Sale can say in his October 22 letter to Judy Mull ins, "Of course I agree that 
standard Pascal must be adhered to" and also say that it is best in specific cases to 
add features that all Burroughs Algol programmers are used to. Pascal was meant to be 
a departure from the past. See also the article "Experience from the Standardization 
of the SIMULA Programming Language", by Jacob Palme, SOFTWARE, Practice and Experience 
Vol. 6, No. 3 July-Sept, 1976, pp 405-409. (It seems that each issue of SOFTWARE, 
Practice and Experience always has some good articles for the practical programmer!) 

We are indeed in a unique position in computer science history as people (rather 
than large organizations) responsibly influencing an influential language. 

PART II - Pascal User's Group and Pascal Newsletter 

1) PUG has 516 members in 22 countries and 43 states. (We had 317 at last writing.) 
I'm sorry this newsletter is so late. But this year the November issue will have in it 
feedback to the September issue. 

2) Ms. Judy Mullins and Prof. D. W. Barron of the University of Southampton have 
done us all a favor by creating a European distribution center for PUG newsletters and 
a clearing house for PUG memberships in the United Kingdom! Judy was concerned that 
members in the U.K. would not get fast mail service, while at the same time having to 
pay a relatively high exchange rate for $4. We in fact had decided to send the first 
2 newsletters (#5 & #6) air mail because we could afford it and Pascal needed the shot 
in the arm. What has transpired between Southampton and Minnesota is no less than 6 
Tetters east to west and 5 letters and a phone call west to east on the subject of 
cheaper ways to send the newsletters (air freight, etc.) These 11 letters are not 
reproduced here; they mostly contained calculations and mechanics of mailing. 

3) While we are on the subject of finances, I'm happy to report that we're doing 
just about right. We've been able to afford to send out 250 issues of #4, and do a 
large mailout requesting implementation information. We still plan to print and mail 
#7 and #8, so don't worry. The next sheet contains a breakdown: 



516 members @ $4 
8 members not paid yet 
6 members for 2 years 
1 member for 5 years 
ABM + JPS contribution 



$2064.00 
32.00 

24.00 extra 
16.00 extra 
29.00 



postage, mass mailings 
refunds for overpayment 
printing and mailing #5 
buying 230 copies of #4 
postage for #5 backissues 
printing newsletter titles 



$2101.00 Total Assets 

$ 52.00 
4.00 
487.10 (700 printed, 368 mailed) 
100.00 no bill for mailing yet 
27.40 so far 
5.60 



$676.10 Total Expenses 



Theoretical balance = 2101.00 - 676.10 = 1424.90 



Cash on hand 
PUG UCC Account 

Actual balance = 



$ 77.76 
$1353.30 

$1431.06 



4) Backissues. Seethe section in HERE AND THERE. Our, offer to send #4 to persons 
in North America who didn't already get one directly from George Richmond expired on 
October 2nd. We simply ran out. But we did buy time . And now the problem of trying 
to include information in #5 that was in #4 is not as acute because #6, #7, and #8 
will gradually make up for that. We will be updating nearly all the news which appeared 
in #4. So for those of you who joined after October 2nd and still want the newsletter 
#4, order one from George Richmond. 

5) I apologize for announcing our policy of: "all the news that fits, we print" in 
the same issue that we put the policy into practice. We modelled the policy after 
SIGPLAN Notices . Feedback to Newsletter #5 has been mostly favorable; the unfavorable 
comments have been largely unwritten. Some heretofore unwritten comments went like this: 

"Your organization could be improved." 
"It was fun reading the News section in HERE AND THERE." 
"It's good to see the correspondence you had with Zurich." 
"It's taken a long time to get my newsletter in the mail." 
"The articles you printed weren't so hot." 
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6) Last issue we tried to plan events so that you would receive the newsletter <"-> 
at the beginning of September. But we didn't come close. Our cutoff date for material ,_ 
was supposed to be July 15, but it lagged to July 31. We began putting the newsletter 

together July 24. We went to press August 13 (and here's the bad news) 25 days later m 

we got our 700 copies on September 7. We had it all in the mail September 9. In the ^ 

U.S. we know (so far) that some arrived as late as October 2! This issue will probably . ,_- 

arrive by Christmas (no kidding) but we began November 4 to put it together and we are m 

going to press November 15 - much better than last time, except we have a late start. __, 

Our cutoff for material for this issue was originally October 1 but lagged to November rn 

5. Issue #7 will probably be smaller as it will go to press probably before we get 
reaction to this issue. By being smaller, it also won't cost as much to print. =^= 

7) Offers to help. In #5, N. Solntseff and W. Richard Stevens offered to help 

with the User's Group. Now that some things have been established, several tasks are 

becoming clear. These are: 

. managing distribution of software writing tools for Pascal 
written in standard Pascal 

. ! managing distribution or cataloging of library and applications 
, programs for Pascal written in standard Pascal _, 

. maintaining a bibliography on all publications about Pascal o 

; (including articles and books) < 

Any takers? - s 

8) Two encouraging trends. First, with microprocessor interest spreading (real cj 
computer power to the people!) it is important to have a Pascal subset compete with ^ 
BASIC in 16K. Mark Rustad understands this very well - see his Motorola 6800 *■ 
description in IMPLEMENTATION NOTES. Mark would like to hear from those persons ^ 
interested. Second, John and I have been getting lots of inquiries about Pascal and to 
implementations in the form of phone calls and letters - with most of them from cn 
persons in industry . Predominate are small software writing firms and minicomputer 

companies. So next time someone says Pascal is okay, but it's not "real world" 
tell them that it's happening right now. 

9) Thanx are due to all the people who have sent in information to print - that 
makes the newsletter. Thanx to John, Tim Bonham, Jim Miner, and Herb Rubenstein for 
halping put together this issue. 
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PASCAL NEWSLETTER #6 NOVEMBER, 1976 PAGE 4 

ANNOUNCEMENT OF A PASCAL USERS 1 GROUP 
DISTRIBUTION CENTRE IN THE 
UNITED KINGDOM 

AIMS 

1. To expedite distribution of the P.U.G. Newsletter to the U.K. and the rest of 
Europe, the Near and Middle East and Northern Africa. 

2. To collect memberships in P.U.G. from U.K. members avoiding high bank charges 
on transfers of £ to $. 

DISTRIBUTION 

1. Central P.U.G. at Minnesota will send the original of the newsletter to 
Southampton for reprinting. 

2. Newsletters will be mailed (second-class postage) from Southampton to members in 
Europe, the Near and Middle East and Northern Africa. 

PASCAL USERS' GROUP MEMBERSHIPS 

1. The address for U.K. Region memberships is 

Pascal Users' Group 
c/o Judy Mull ins 
Mathematics Department 
The University 
SOUTHAMPTON. S09 5NH 

(telephone 0703-559122 x2387) 

2. Members can pay €2.50 by cheque or postal order to PASCAL USERS' GROUP (UK) 

at the above address, and will receive a receipt and member certificate directly. 

3. Membership forms will be forwarded at short intervals to Minnesota (at least in 
time to catch the next newsletter }; a copy is kept at Southampton. 

AVOIDING CONFUSION 

1. There is only one membership list and labelling program - Minnesota's. 

2. Therefore anyone can join directly by writing to the U.S.A. 

3. Using the U.K. Distribution Centre only saves money. 

4. No matter how he/she joined, a member with an address in the U.K. will receive 
newsletters via Southampton. 

5. All correspondence other than subscriptions (such as change of address, articles 
for the newsletter, or questions about compilers) must go direct to Minnesota. 
If it inadvertently arrives at Southampton it will be sent on by airmail. 

August, 1976. * J.M. Mullins. 

Rev. November, 1976. A.B. Mickel. 



MEWS (alphabetical by last name) 

A. M. Addyman , Department of Computer Science, The University, Manchester M13 9PL 
United Kingdom {PUG member): "I would like to join the Pascal Users' Group. 
Also, I am engaged in an effort to have Pascal standardised by a major 
standard's organisation, e.g. ANSI or ISO. How may I use your newsletter to 
contact people who would be interested in this, or alternatively to discover 
that there is considerable opposition?" (*8/10/76*) 

Urs Amman n , Institut fur Informatik, ETH - Zentrum, CH-8092 Zurich, Switzerland 
(PUG member): "...By the way: What is your philosophy with the letters you 
received as to their publication in the Newsletter? I was somewhat astonished 
to see private correspondence in it. While I agree that this kind of 
information distribution makes editorship most easy, it is my strong opinion 
that any letter which is not explicitly marked as "letter to the editor" should 
not be published in full length, since this clearly exceeds or even 
contradictes (sic) the purpose of private correspondence. 

"Please don't misinterpret this statement! I have nothing against transparency, 
on the contrary! Any information of general interest you find in your 
correspondence should be passed on. But you will agree that with some effort 
from the editor, information can be passed on without letting everybody read 
private correspondence " (*9/29/76*) 

Diosdado P. Banatao , 3060 Bilbo Drive, San Jose, CA 95121 (PUG member): "I 
would like to be a member of the Pascal Users Group... My interests are in 
microprocessors and microcomputers and involved in both hardware and software 
design..." (*10/19/76*) 

Philip N. Bergstresser , 128 Jackson Ave., Madison, AL 35758 (PUG member): "We 
at TRW Systems are using Pascal on the CDC 7600, CDC 6400 and TI-ASC and claim 
the Guinness record for program size." (*9/21/76*) 

Frank M. Brewster , 4701 Kenmore Ave #1009, Alexandria, VA 22304 (PUG member): 
"...It's been pointed out that many BASICS are 'non-standard'. I have yet to 
hear anyone ask, 'Why?'. The answer seems obvious: the language initially didn't 
have 'legal' provision for many of the users' real problems. The current ANSI 
BASIC proposal still demonstrates this failing. E.g., the CHR and SEQ(or 0RD) 
functions are optional; how can anyone do general work without these functions? 
So BASICS will continue to be 'non-standard', as people fill in the gaps. If a 
car were sold without say, steering wheel, no one should complain if a buyer adds 



a tiller. The point is that if the automotive designer finds steering wheels 
uninteresting and refuses to specify them as standard equipment, the user has 
two options (assuming he buys the car in spite of its failings): design his own 
steering apparatus, or cooperate with others in filling the gap in the 'standard'. 
If the designer won't see the issue, users will. The letters in the newsletter 
mention, e.g., array passing and formatted input problems. Apparently Wirth's 
not concerned. If you and others do nothing, then everybody either abandons 
Pascal or invents their own wheel (tiller?). But why don't those of you with 
early and practical experience with the language- 
-list your complaints & problems, ranked, one list per man. (Maybe in a newsletter 

section, 'What's wrong with Pascal?'?) 
-compare notes for similarities 
-see if you can agree on solutions to any of these 
-implement experimental changes; test till working 
-promulgate as PUG-US 'extensions' 

"The last item is the tackiest one. "A camel is a horse designed by a committee." 
Standards - the real ones, in actual use - are designed by those who are actually 
working in the field, in the course of their work. So if you and other of the 
few presently experienced Pascal users won't add to or alter Wirth's 
pronouncements, don't be surprised at the later irreverence of others. 
"All of you (me too someday) may owe a lot to Wirth. His opinions deserve 
respect and attention. But if he's to be treated as God, and his language as the 
ten commandments, how can Pascal be improved? The time to 'standardize' is not 
now, but after user problems have been faced frankly, and solutions found..." 
(*10/29/76*) 

C- E - Bridge , E.I. Du Pont de Nemours & Co., Engineering Development Lab, 101 
Beech Street, Wilmington, DE 19898 (PUG member): "Have: PDP-11 series machines: 
04, 05, 10, 15, 20, 40, 45. Using: (1) Prof. Per Brinch Hansen Solo Pascal 
Compilers, (2) University of Illinois DOS V4 Pascal Compiler, (3) Pascal P2 
System. 

"All of the above systems have their drawbacks. My interest is in a better 
transportable system for use on uCPU applications. I am very happy with the 
CDC 6000 version 3.4 at Purdue University; however, achieving the same degree 
of performance on a mini -computer has been and will continue to be a challenge 
Mr. Stephen C. Schwarm, a coworker, is in the process of starting a DECUS 
SIG PASCAL for PDP users of Pascal." (*9/13/76*) 
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HERE AND THERE WITH PASCAL 

(NEWS FROM MEMBERS, CONFERENCES, NEW BOOKS, APPLICATIONS PROGRAMS, ETC.) 



HERE AND THERE WITH PASCAL 



(NEWS FROM MEMBERS, CONFERENCES, NEW BOOKS, APPLICATIONS PROGRAMS, ETC) 

K - Frankowski , Computer Science Dept. , 114 Lind Hall, University of Minnesota, 
Minneapolis, MN 55455 (PUG member): "If one wants to have formatted reads, 
simply read several integers (if they are run together) as one integer and use 
div and/or mod to extract the values desired." (*10/15/76*) 

Dennis Graham , Amdahl Corp., 1250 E. Arques Ave., Sunnyvale, CA 94086 (PUG member) 
"I am interested in running Pascal on an AmdahT-470 V/6 system and am contacting 
the University of Manitoba about their compiler." (*10/26/76*) 

David J. Griffiths , Academic Computer Centre, Tyler Hall, University of Rhode 
Island, West Warwick, RI 02881 (PUG member): "I am investigating the possibility 
of implementing Pascal on our IBM360-370. Concurrent Pascal would be the ideal, 
since we wish to investigate more advanced operating systems, however, we are 
prepared to settle for less." (*10/3/76*) 

Donald E. Grimes , 90 Sylvia Street, Arlington, MA 02174 (PUG member): 
"Congratulations on a timely Newsletter #5, and thanks for your efforts in 
establishing PUG." (*10/8/76*) 

Charles Hedrick , 183 Commerce West, University of Illinois, Urbana, IL 61801 
(PUG member): "When considering operational definitions of portability maybe 
it is useful to distinguish among versions that are: 
-machine independent 

-semi-machine dependent and concepts universal 
-machine dependent and site independent 
"The last choice may not be so bad for Pascal to shoot for." (*10/15/76*) 

Carl Henry , Computer Center, Carleton College, Northfield, MN 55057 (PUG member) 
"...We are using... the University of Illinois version (Mickunas, et al ) and 
runs under DOS V4 on an 11/20, (very little use has been made of it so far.). 
"A brief description of our facilities: 6 PDP-8s - home brewed version of 
TSS/8 and OS/8; PDP 11/20 - DOS, RT-11, RSTS V4; PDP-11/40 - RSTS V6, UNIX V6." 
(*10/15/76*) 

Mark Hersey , 323 Village Drive Apt. 534, East Lansing, MI 48823 (PUG member): 
"currently modifying P2 version of Janus compiler for readability, fixing bugs, 
expanding subset processed, and improving portability. 

"All work being done on Michigan State University's CDC 6500." (*10/4/76*) 

Brian W. Johnson, 1525 Westlake, Piano, TX 75075 (PUG member): "I am 
particularly interested in /j processor versions. We have it on the PDP-10 
and PDP-11 at UT Dallas." (*ll/4/76*) 



Willett Kempton , 2512 San Gabriel St., Austin, TX 78705 (PUG member): "Thanks 
for the newsletters. ... I was delighted to see that dynamic array parameters 
will be implemented in CDC Pascal; this is clearly an extremely important 
feature, and I would urge that it become a feature of the standard language , 
rather than an extention available in some implementations (and not others). 
"Keep after those implemented to accept standard Pascal programs!!" (*10/27/76*) 

C. A. Lang , Cambridge University Press, Pitt Building, Trumpington St., 
Cambridge CB2 1RP, United Kingdom (PUG member): "We are interested in 
publishing books concerned with Pascal." (*10/26/76*) 

Michael Lutz , School of Computer Science and Technology, Rochester Institute 
of Technology, Rochester, NY 14623 (PUG member): "...I would also appreciate 
any information you might have on Pascal implementations for the Xerox 
(Honeywell) Sigma 5 - 9 and PDP 11 computers. We have both a Sigma 9 and a 
PDP 11/T34 (with 48K words of memory) here at R.I.T., and we are interested 
in obtaining Pascal for use in our courses " (*10/27/76*) 

John Montague , Los Alamos Scientific Laboratory, Group Cll - Mail Stop 296, 
Los Alamos, NM 87545 (PUG member): "...We plan to bring up Pascal on the 
CRAY-1, probably using the P-code compiler to bootstrap." (MO/18/76*) 
Jud y MLLLm» Computer Studies Group, Department of Mathematics, The University, 
Southampton S09 5NH, United Kingdom (PUG member): "...Pascal is alive and 
happy in Southampton. One hundred nineteen-year-olds are pushing in programs 
by the hundreds ... and doing amazingly well. I do believe it is the language 
that is so friendly that increases their interest and output... 
"...I was wondering if it would be appropriate to have a section of PUGN for 
exchange of course ideas, examples etc. This would have to be firmly 
controlled space-wise, but could prove very informative expecially for 
universities who have Pascal but don't teach it yet. Later on a survey on the 
use of Pascal in teaching would be of great interest. Addyman's survey 
showed Pascal is growing and therefore its growth should be monitored every 
year, 

"Another thought was for book reviews. Pascal primers are beginning to 
proliferate and we have strong views on the ones we've seen. Once again, to 
have the right effect this section would need to be controlled, and I'm not 
sure that we want to start issuing PUG marks of approval or anything like that. 
However, reviews in normal journals are only opinions and it does seem fitting 
for opinions of Pascalers on Pascal books to be in the Pascal Newsletter." 
1*11/3/76*) 
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Fred Powe]J_, Computer Center, Mary Baldwin College, Staunton, VA 24401 (PUG 
member): "We have Pascal P2 and are interested in implementing Pascal on an 
IBM 1130 and possibly a System 3. Other possibilites include investigating 
data bases and disk access techniques with Pascal." (*9/24/76*) 

Douglas H. Quebbeman , 2235 Lombardy Drive, Jeffersonville, IN 47130, (PUG 
member): "...Having seen the article in the June '76 Random Bits (Indiana 
University's Computing Center Newsletter) on the Pascal User's Group, I 
decided to join. I am a student and part-time operator - programming 
consultant and have only recently begun using Pascal, but I am quite enthuse v d 
about its flexibility (especially considering my wrestling bouts with Fortran) 
and hope to become more proficient in it. So, thanks (for forming the User 
Group) and I hope to hear from you soon." (*9/24/76*) 

Peter A. Rigs bee , Code 5494, Naval Research Laboratory, Washington, DC 20375 
(PUG member): "...My connection with Pascal is that my group is trying to get 
Per Brinch Hansen's SOLO operating system to run on a PDP 11/40, and once this 

is done, will be using Pascal as a primary systems programming language " 

(*8/25/76*) 

Sergio de Mello S chneider , Departamento de Computa^ao, Univ. Federal de S. 
Carlos, C.P. 384, 13560 S. Carlos SP, Brazil (PUG member): "We have a 
HP 2100A at our installation (32K words core, 2 disks, 1 tape, DOS) and we 
are looking for a Pascal compiler. There is no way we can produce one in 
the next 3 years. Could you help us?" (*10/21/76*) 

Stephen C. Schwann, E. I. du Pont de Nemours Co., 101 Beech St., Wilmington, 
DE 19898 (PUG member): "I am chairman of DECUS SIG Pascal and I will be glad 
to help with distribution any systems on DEC PDP-ll's." (*10/29/76*) 

Dave Tarabar , Data General Corp., Field Engineering, 235 Old Connecticut Path, 
Framingham, MA 01701 (PUG member): "I was very pleased to receive and read 
the first PUG Pascal Newsletter. It was full of interesting information. 
The newsletter will be very useful in publishing the correspondence with 
Zurich and other implementors and your summary of all known implementations 
was great. Keep up the good work." (*10/18/76*) 

William P. Taylor , L-315, University of California, PO Box 808, Livermore, CA 
94550 (PUG member): "I am interested in obtaining information about 
implementations of Pascal on 16-bit mini -computers. I am especially interested 
in implementations for the PDP-11 as we will be getting one soon. Also, some 
of my fellow employees here at Lawrence Livermore Laboratory wish to implement 
a structured programming language like Pascal for system development on a new 

mini -computer." (*10/3/76*) 



APPLICATIONS PROGRAMS 

STANFORD UNIVERSITY 

Stanford Linear Accelerator Center 
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Mail AJJrtsi 

SLAC, P. O. Box 4349 
Stanford. California 94303 

IP October, 1976 



Request for Programs 



Pacal Users: 

1 am presently doing research on Pascal to determine 
how various parts of the language are used and what patterns 
of execution occur In actual programs. This will he similar 
to a study done by Knuth on Fortran (1). 

In this regard I am interested in obtaining a sample of 
programs *ror. a wide range of users In hopes that the results 
of this sffdy might be representative of the actual use of 
Pascal . 

If you have or know of programs which can be lent to this 
effort/ 1 would very much like to hear from you. I can be 
contacted by ma 1 1 at 

flail Drop 88 

Stanford Linear Accelerator Center 

P. O. Pox 4349 

Stanford, CA. 94305 



or by phone at 



(415) 854-3300 X2802. 



John Banning 



(1) D. E. Knuth, "An Empirical Study of FORTPAM Programs 1 ', 

Software Practice and Experience . Vol. 1 (1971), 195-133. 



(*Note: John also enclosed a note which said: "With regards to the enclosed 
request, I expect that the mentioned study will complete sometime in the 
first quarter of 1977. I would be most happy at that time to provide a 
summary of the results for the Newsletter if you are interested - ... Does 
there exist some formal mechanism for Pascal program interchange (between 
users), and, if so, who is running it and how can I contact them?"*) 
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THIRD ANNUAL COMPUTER STUDIES SYMPOSIUM 



UNIVERSITY of SOUTHAMPTON 



* 

b 



A 

A A 

A A 

A A A A 

A A 

A A A A 

A A A A 

AAAAAAAA 

A A 

A A A A 

A A A A 

AAAA AAAA 

A A A A 

A A AA AA AA 

A A A A AA A A 

AAAAAAAAAAAAAAAA 

A ■ ■ A 

A A A A 

A A PASCAL A A 

AAAA AAAA 

. A A A A 

a a a a IMPLEMENTATION A A A A 



AAAA 
AAAAAAAA AND 

A a APPLICATIONS 



A A 

A A 

AAAA 

A A 

A A A A 

A A A 



A A 

A A 

AAAA 

A A 

A A A A 

AAAA 



A A A A 

AAAAAAAA 

A A 

A A A A 

A A A A " 

AAAA AAAA 

AAAA 

A A AA AA AA 

A A A A AAAA 



A A A A A A A A A AAAA A A AAAAAAAAAAAA A A AAA 



AIMS 



Few languages since FORTRAN have had the same 
run-away success as Niklaus Wirth*s PASCAL, which shows 
signs of becoming a de facto standard for Computer 
Science teaching and research, as well as pointing 
the way to a new generation of sparse, simple languages. 

She purpose of this symposium is to explore 
"what's going on" in PASCAL at the present time. 
Leading authorities will describe new implementations 
and applications in systems programming, research and 
education. The symposium will end with an open 
discussion about the future of PASCAL. 

In the tradition of the Southampton symposium, 
speakers will be allowed ample time for their 
presentations, together with provision for a discussion 
at the end of each lecture. Attendance will be kept 
to 100 and it may be necessary to limit applications 
from each institution. Applicants are expected to 
have a working knowledge of PASCAL. 

Full preprints of the Proceedings will be 
available on registration; the Proceedings will 
subsequently be published in book form. 



21 and 25 MARCH 1977 



SYMPOSIUM CHAIRMAN 

Professor D.W. Barron 



SYMPOSIUM ORGANIZER 
Miss J.M, Mullins 



SPEAKERS 



PROGRAMME 



Dr.Urs Ammann 

Techni s ch e Hochs chul e 

Zurich 

SWITZERLAND 

*** 

Prof .David Barron 
Mathematics Department 
The University 
SOUTHAMPTON 



Dr.Mike Rees 
Computer Studies Group 
The University 
SOUTHAMPTON 



Dr .David Watt 

Computer Science Department 

University 

GLASGOW 



IMPLEMENTATION 



Br ,U. Ammann 
Dr .J.Welsh 

Dr. D. A. Watt 
Dr. M.J. Rees ^ 
Miss J.M. Mullins 



The Zurich Compilers 
Two ICL 1900 Compilers 

A Diagnostic System 

PASCAL on an Advanced Architecture 

A PASCAL Machine? 



Dr. Per Brinch Hansen 
Computer Science Program 
University of Southern 

California 
LOS ANGELES 



Dr. Graham Webster 

Computer Science Department 

Teesside Polytechnic 

Middlesborough, 

CLEVELAND. 



APPLICATION 



Dr.P.Brinch Hansen Concurrent PASCAL 
Dr. G.Webster PASCAL in Education 
Dr. B.Hood PASCAL in Research 



Dr. Barry Hood 
Electronics Department 
The University 
SOUTHAMPTON 



Dr. Jim Welsh 

Computer Science Department 

Queen's University 

BELFAST 



THE FUTURE 



Panel Discussion introduced by Prof .D.W.Barron 



Miss Judy Mullins 
Computer Studies Group 
The University 

SOUTHAMPTON 



BOOKS and ARTICLES 

(*There has been no news of new books on Pascal. In future issues of the 
Newsletter, we should also list current articles appearing in journals and 
other computer science literature. Apologies for the void in this section 
in this issue.*) 



A. M. Addyman and H. R. Addyman, "Which Language?", Computer Bulletin , 

June, 1976, pp 31-33. [an article which surveys the language 
used at various institutions teaching computer science] 

(*Last issue there were a couple mistakes in the list of books; these are 

corrected below.*) 

A Primer on PASCAL by Richard Conway, David Gries, and E. C. Zimmerman, 
Winthrop Publishers, 1976, 448 pages, paperbound, $9.95. 

Introduction to Problem Solving and Programming with Pascal , by G. Michael 
Schneider, Steven W. Weingart, and David M. Perlman, Wiley, to 
be published in late 1977. (*A complete soft cover manuscript 
will be available March 1, 1977 and may be ordered from Michael 
Schneider, Computer Science Department, 114 Lind Hall, University 
of Minnesota, Minneapolis, MN 55455. Such copies may be 
duplicated(once received) for local use.*) 

PASCAL User Manual and Report , by Kathleen Jensen and Niklaus Wirth, 
Springer-Verlag, 1974, 1975, 167 pages, paperbound, $5.90, 
Second (study) edition. (*This book is selling well; it's in 
its third printing which now incorporates the errata that 
appears on the next page as reproduced from Newsletter #4. In 
Newsletter #5 we printed out of date errata because no one 
kindly informed us of anything more up to date. So like the 
implementation notes, we are only as good as what people send 
us to print. Note that this errata includes the change to the 
language Pascal - namely the generalization of the read and 
write procedures to perform I/O on files of any type, not just 
text files.*) 
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and Report 
Second Edition. 



KEY: 

p = page number 

] = 1 ine number 
(blank lines 
are ignored 
and negative 
1 ine numbers 
are counted 
from the 
bottom) 

c = code 
(that is: 
r = replace 
i = insert) 



O 1 C 

13 -3 r 

45 -18 r 

51 16 r 

56 -6 r 

63 2 r 

69 23 r 

70 7 r 

77 13 r 

78 -14 r 
81 2 r 
84 -15 r 
86 8 i 



87 8 i 



98 

102 

102 

103 

103 

105 

105 
105 



10 r 

7 r 

20 r 

-6 r 

-7 r 

r 

12 r 
-1 i 



117 r 

120 -18 r 

121 4 i 



121 



8 i 



121 


-8 


i 


124 


-15 


r 


124 


-14 


r 


127 


27 


r 


133 


3 


r 


135 


« 5 


r 


135 


30 


r 


140 


11 


r 


161 


-17 


r- 



161 -16 r 

162 3 r 
162 -=15 i 



if by "if" 

<unsigned constant>" by "<constant>" 
"(output)" by "(output);" 
"fi" by "f(i)'\ B g(i + 1)" by "g(j + l)'\ 



"gi" by "g ( j )* 



3" by "n~2", 



by "kaaijl inorder(pT .llink):" 



1 by "n", "2" by "n-1" f " 
"(n-1)" by "2", "n " by "1" 

"stricly" by "strictly" 

,e i,j" by "i" 

bjsalxi inorder(pT . llink) 

" * <formal" by "; <formel" 

"extent" by "extend" 

as ne" by "as one" 

The procedure read can also be used to read from e file f which 
is not a textfile. 

read(f,x) 
in this case stands for 

besln x :» fT ; get(f ) e_njl 

The procedure write can also be used to write onto a file r 
which is not a textfile. 

write (f,x) 
in this case stands for 

JfesaLtn fT :- x; put(f ) end 
"debby" by "debby '•" 

r" by "or" 
"bufffer" by "buffer" 
"scaler'" by "scalar" 

char, and alfa" by "and char are listed" 
" by "105° 

nly" by "only" 
dispose (p ,t 1 ,... ,tn ) Can be used to indicate that storage occu- 
pied by the variable pi (with tag field 
values t1...tn) is no longer needed. 

(diagram expression) "^ " by "<»", "^ " by "> = " , 'V by "<>" 

"neither be formal nor non local" by 

not be declared on intermediate level" 

177: assignment to function identifier not allowed here 
multidefined record variant 

X-opt of actual proc/func does not match formal declaration 
control variable must not be formal 
constant part of address out of range 

205: 
206: 

260 i 

"14" 

*°14" by "15" 

"18. A " by ^.A* 

"two" by "to" 

tl though" 

"substitute" 

'structured type" 



178: 
179: 
180: 
181: 



zero string not allowed 

integer part of real constant exceeds range 

too many exit labels 
by "15" 



al thought by '<■ 
"subtsti tute"' by 
"structure type" by 



the procedures sioX, and jaaX * The textfiles these 
to must not necessarily represent' 



162 



6 i 



whole 1 ine by 

"addition to 

who3e line by 

"standard procedures apply 

"find'flf line" by *jjnd u.f lijje" 

The procedure read can also be used to read from a file f which 
is not a textfile. read(f t x) is in this case equivalent to 
x :* fT ; ciel(f), 

The procedure write can also be used to write onto a file f 
which is not a. textfile * write (f»x) is in this case equivalent 

to fT :* x; put(f). 



PAST ISSUES OF Pascal Newsletter 

Reproduced below is a complete description of Newsletters 1, 2, 3, and 4. 
Numbers 1,2, and 3 are out of print , but they di_d appear in issues of SI GPL AN 
Notices , the ACM Special Interest Group on Programming LANguages monthly 
journal. Number 4 is available for $1.00 from George H. Richmond, Computing 
Center, 3645 Marine Street, University of Colorado, Boulder, CO 80309. 

#1 January, 1974 (also SIGPLAN Notices Vol. 9 No. 3 1974 March) 8 pages. 
Table of Contents 

1 From the Editor 

1 Current CDC Pascal Compiler 

5 Cost of the CDC Compiler 

5 Forthcoming Versions of the CDC Compiler 

6 Other Pascal Compilers 

7 Modifications to CDC Pascal 

7 Other Documentation 

#2 May, 1974 (also SIGPLAN Notices Vol. 9 No. 11 1974 November) 18 pages. 
Table of Contents 

1 From the Editor 

1 History of Pascal 

2 Pascal for non-CDC machines 
6 Pascal 6000-3.4 - N. Wirth 

18 Pascal and Portability - N. Wirth 

#3 February, 1975 (also SIGPLAN Notices Vol. 11 No. 2 1976 February) 19 pages. 
Table of Contents 

1 From the Editor 

1 Pascal User Manual and Report 

3 Pascal Questional re Results 

4 History of Pascal, Revised - G. Richmond 

8 Bib! iography 

10 Portable Pascal 

11 A Generalization of the Read and Write Procedures - N. Wirth 

12 Corrections to Pascal 6000 - 3.4 

13 Pascal 6000 - 3.4 Interactive Operation 
13 Letters to the Editor 



"O 
GO 



4 July, 1976 (copies may be obtained for $1.00 from George Richmond, 

the editor, as explained on the previous page) 103 pages. 
Table of Contents 

From the Editor 

1 Correspondence 

(altogether 36 letters and notices including much 
implementation information) 
81 A New Release of the Pascal -P System - Ch. Jacobi 
86 Errata, PASCAL User Manual and Report (Second Edition) 
88 Pascal User's Group 
90 Pascal Implementors List 

100 Bibliography (Literature about the Programming Language 
Pascal) 
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ROSTER 11/14/76 ' 

For our mutual benefit in 
communication, here is the 516 
member PUG roster spanning 22 
countries and 43 states. It is 
sorted (intelligently, we think) 
by zip (mail) codes (U.S. first) '. 
and then alphabetically by country. 
You can see at a glance who is at 
a well known organization at a 
well known place or who is in your 
area (or on your street!). Now, 
if you need an index by last name, 
there is one at the end, cross- 
referencing with zip (mail) code. 
*********** 



HENRY F. LEDGARD 
COMPUTER AND INFO. SCI . 
U OF MASSACHUSETTS 
AMHERST MA 01002 
(413) 545-2744 



NORMAN E. SONDAK 

COMP. SCI. DEPT. 

WORCESTER POLYTECHNIC INSTITUTE 

WORCESTER MA 01609 

(617) 753-1411 



HANK EDWARDS 

2C BRACKETT ROAD 

FR AM INGHAM MA 01701 

(617) 620-1066 (HOME) 

(617) 897-5111 X6809 



DAVID TARABAR 
FIELD ENGINEERING 
DATA GENERAL CORPORATION 
235 OLD CONNECTICUT PATH 
FRAM INGHAM MA 01701 
(617) 620-1200 



LLOYD DICKMAN 

25 HAWTHORNE VILLAGE 

CONCORD MA 01742 



ATTN: LIBRARY 

ML5-4/A20 

DIGITAL EQUIPMENT CORPORATION 

MAYNARD MA 01754 



RONALD F. BRENDER 

BLISS LANGUAGE DEVELOPMENT 

ML3-5/E82 

DIGITAL EQUIPMENT CORP. 

146 MAIN STREET 

MAYNARD MA 01754 

(617) 897-5111 X2520 

ALBERT S. BROWN 

PK3-1/M12 

DIGITAL EQUIPMENT CORP. 

146 MAIN STREET 

MAYNARD MA 01754 

(617) 897-5111 X2391 



N. AMOS GiLEADI 

APPLIED SYSTEMS GROUP 

ML 21-4 E-20 

DIGITAL EQUIPMENT CORP. 

146 MAIN STREET 

MAYNARD MA 01754 

(617) 897-5111 X4402/X3888/X6472 

RONALD J. HAM 

ML5-5/E40 

DIGITAL EQUIPMENT CORPORATION 

146 MAIN STREET 

MAYNARD MA 01754 

(617) 897-5111 



EDWARD STEEN 
119 SHERMAN STREET 
LOWELL MA 01852 
(617) 454-9320 



AARON SAWYER 

DEPT 330 

THE FOXBORO COMPANY 

FOXBORO MA 02035 

(617) 543-8750 X2029 



WARREN R. BROWN 

D.330 

THE FOXBORO COMPANY 

38 NEPONSET AVE. 

FOXBORO MA 02038 

(617) 543-8750 X2023 



VICTOR S. MILLER 

DEPT OF MATHEMATICS 

BLDG 2 

U OF MASSACHUSETTS 

HARBOR CAMPUS 

BOSTON MA 02125 

(617) 287-1900 X3170/X3161 

MICHAEL MEEHAN 
WINTHROP PUBLISHERS 
17 DUNSTER STREET 
CAMBRIDGE MA 02138 
(617) 868-1750 



ATTN: READING ROOM 

INFORMATION PROCESSING CENTER 

39-430 

MIT 

CAMBRIDGE MA 02139 



GABRIEL CHANG 
575 TECHNOLOGY SQUARE 
HONEYWELL INFORMATION SYSTEMS 
CAMBRIDGE MA 02139 
(617) 491-6300 



JEANNE FERRANTE 
125 ANTRIM ST. 
CAMBRIDGE MA 02139 
(617) 876-8635 



R. STERLING EANES 

SOFTECH 

460 TOTTEN POND ROAD 

WALTHAM MA 02154 

(617) 890-6900 



R. KRASIN 

FIRST DATA CORP. 

400 TOTTEN POND ROAD 

WALTHAM MA 02154 

(617) 890-6701 



DAVID SOLOMONT 
COMPUTER SERVICES 
MILLER HALL 
TUFTS UNIVERSITY 
MED FORD MA 02155 
(617) 628-2943 



PETER COLBY 
289 MILL ST. 
NEWTONVILLE MA 02160 
(617) 527-2394 



CHRISTOPHER K. JOHANSEN 
FREEKSHOW ELECTONWORKS 
176 GROVE STREET 
AUBURNDALE MA 02166 
(617) 969-2399 
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GEORGE POONEN 

15 ORCHARD AVE. 

WABAN 

(617) 969-4684 



MA 02168 



BERN J E ROSMAN 

MATH/CS DEPT. 

FRAM INGHAM STATE COLLEGE 

FRAM INGHAM MA 01701 

(617) 872-3501 



WILLIAM F. SHAW 

ML5-5/E40 

DIGITAL EQUIPMENT CORPORATION 

146 MAIN STREET 

MAYNARD MA 01754 

(617) 897-5111 



F. J. CORBATO 

NE43-514 

MASSACHUSETTS INSTITUTE OF TECHNOLOGY 

545 TECHNOLOGY SQUARE 

CAMBRIDGE MA 02139 

(617) 253-6001 



DONALD E. GRIMES 
90 SYLVIA STREET 
ARLINGTON MA 02174 
(617) 646-4129 
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MICHAEL HAGERTY 
18 HAMILTON ROAD 
ARLINGTON MA 02174 
(617) 492-7100 



RICHARD D. SPILLANE 
DEPT OF MATH/C.S. 
WILLIAM PATTERSON COL. 
WAYNE NJ 07470 
(201) 881-2158 



T. A. D'AURIA 

CENTER FOR COMPUTING ACTIVITIES 

COLUMBIA UNIVERSITY 

NEW YORK NY 10027 



NEWTON J. MUNSON 
COMPUTING CENTER 
CLARKSON COLLEGE 
POTSDAM NY 13676 
(315) 268-7721 



GO 

3> 



TERRENCE M. COLLIGAN 
RIVERSIDE OFFICE PARK 
MANAGEMENT DECISION SYSTEMS 
RIVERSIDE, ROAD 
WESTON MA 02193 
(617) 891-0335 



RON PRICE 

PERKIN-ELMER DATA SYSTEMS 
INC. 106 APPLE ST. 

TINTON FALLS NJ 07726 



WILLIAM BARABASH 
DEPT. OF COMP. SCI . 
SUNY STONY BROOK 
STONY BROOK NY 11794 
(516) 246-7146 



TED TENNY 

COMPUTER SCIENCE DEPT. 
SUNY - POTSDAM 
POTSDAM NY 13676 
(315) 268-2954 



m 
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DAVID J. GRIFFITHS 
ACADEMIC COMPUTER CENTER 
TYLER HALL 

UNIVERSITY OF RHODE ISLAND 
WEST WARWICK Ri 02881 
(401) 792-2701 



RON OLSEN 

ROOM 3E207 

BELL LABORATORIES 

HOLMOEL NJ 07733 

(201) 949-5537 



GARRY MEYER 
COMPUTING CENTER 
SUNY STONY BROOK 
STONY BROOK NY 11794 
(516) 246-7047 



WILLIAM C. HOPKINS 
207 RIDGE WOOD DRIVE 
AMHERST NY 14226 
(716) 634-6346 






ANDRIES VAN DAM 
BROWN UNIVERSITY 
BOX F 

PROVIDENCE RI 02912 
(401) 863-3088 



ATTENTION: R. D. BERGERON 
DEPARTMENT OF MATHEMATICS 
KINGSBURY HALL 
U OF NEW HAMPSHIRE 
DURHAM NH 03824 
(603) 862-2321 



STEVE LEGENHAUSEN 
12 BARNARD STREET 
HIGHLAND PARK NJ 08904 
(201) 572-6585 



WILLIAM HENRY 

117 E. TENTH ST. 

NEW YORK NY 10003 



M. ELIZABETH IBARRA 
DEPT. OF APPLIED MATH 
BROOKHAVEN NATIONAL LABORATORY 
UPTON NY 11973 
(516) 345-4162 



J. SCOTT MERRITT 
36 OAK WOOD AVE. 
TROY NY 12180 
(518) 271-7553 



G. FRIEDER 

DEPT. OF COMPUTER SCIENCE 

SUNY BUFFALO 

4226 RIDGE LEA RD. 

BUFFALO NY 14226 

(716) 831-1351 



JAMES MOLONEY 
DEPT. OF COMP. SCI . 
SUNY BROCKPORT 
BROCKPORT NY 14420 
(716) 395-2384 
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WILLIAM J. VASILIOU JR. 
COMPUTER SERVICES 
KINGSBURY HALL 
U OF NEW HAMPSHIRE 
DURHAM NH 03824 
(603) 862-2323 



EDWARD R. FRIEDMAN 
CIMS/CS DEPT. 
NEW YORK UNIVERSITY 
NEW YORK NY 10012 
(212) 460-7100 



GEORGE H. WILLIAMS 
EE/CS DEPT. 
UNION COLLEGE 
SCHENECTADY NY 12308 
(518) 370-6273 



MICHAEL J. LUTZ 

SCHOOL OF COMPUTER SCIENCE 

ROCHESTER INSTITUTE OF TECHNOLOGY 

ROCHESTER NY 14623 

(716) 464-2995 
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JAMES P. SHORES 
344 GLENWOOD AVE. 
NEW LONDON CT 06320 
(203) 442 7 0771 X2126 



ROSEMARY HOWBRIGG 
36 MENUNKETESUCK DRIVE 
CLINTON CT 06413 
(203) 669-5812 (HOME) 
(203) 442-0771 X2963 (WORK) 



PETER PAWELCZAK 

UNIVERSITY COMPUTER CENTER 

C/0 LIBRARY 

CUNY 

555 W. 57TH ST. 

NEW YORK NY 10019 



HOWARD D. ESKIN 

CENTER FOR COMPUTING ACTIVITIES 

ROOM 712 

COLUMBIA UNIVERSITY 

612 W. 115TH ST. 

NEW YORK NY 10025 

(212) 280-2874 



J. L. POSDAMER 

SCHOOL OF COMP. AND INFO. SCI. 

313 LINK HALL 

SYRACUSE U 

SYRACUSE NY 13210 

(315) 423-4679 



MICHAEL N. CONDICT 

PATTERN ANALYSIS AND RECOGNITION CORP 

ON THE MALL 

ROME NY 13440 

(315) 336-8400 X36 



RICHARD CONWAY 




DEPT. OF COMPUTER SCIENCE 




CORNELL UNIVERSITY 


j 


ITHACA NY 14850 




(607) 256-3456 




JOHN H. WILLIAMS 
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CORNELL U 
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ITHACA NY 14850 




(607) 256-5033 
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MIKE LEMON 
782 WEBSTER HALL 
4415 FIFTH AVENUE 
PITTSBURGH PA 15213 
(412) 624-6454 



S. L. GULDEN 
DEPT. OF MATH 
LEHIGH UNIVERSITY 
BETHLEHEM PA 18015 
(215) 691-7000 X341 



RICHARD J. CICHELLI 
901 WHITTIER DRIVE 
ALLENTOWN PA 18103 
(215) 797-9690 



C. E. BRIDGE 

ENGINEERING DEVELOPMENT LAB 

E. I . DU PONT DE NEMOURS AND CO. 

101 BEECH STREET 

WILMINGTON DE 19898 

(302) 774-1731 
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GARY LINDSTROM 
COMPUTER SCIENCE DEPT. 
U OF PITTSBURGH 
PITTSBURGH PA 15260 
(412) 624-6455 



V. LALITA RAO 

506 W. THIRD STREET APT. 4 
BETHLEHEM PA 18015 
(215) 865-6448 



CHESTER J. SALWACH 
2124 DIAMOND STREET 
SELLERSVILLE PA 18960 
(215) 723-8301 



STEPHEN C. SCHWARM 

E.I . DU PONT DE NEMOURS CO. 

101 BEECH ST. 

WILMINGTON DE 19898 

(302) 774-1669 



MARY LOU SOFFA 
COMPUTER SCI . DEPT. 
335 ALUMNI HALL 
UNIVERSITY OF PITTSBURGH 
PITTSBURGH PA 15260 
(412) 624-6454 



RAMON TAN 
P.O. BOX 2 

BETHLEHEM PA 180U 
(215) 866-7195 



ROBERT KEZELL 

UNIVERSITY COMPUTER ACTIVITY 
TEMPLE UNIVERSITY 
PHILADELPHIA PA 19122 
(215) 787-8527 



•MIKE FRAME 
FIRST DATA CORP. 
2011 EYE ST. NW 
WASHINGTON DC 20006 
(202) 872-0580 
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HOWARD E. TOMPKINS 
COMPUTER SCIENCE DEPT 
INDIANA UNIVERSITY OF PA 
INDIANA PA 15701 
(415) 357-2524 



STEPHEN TITCOMB 
1111 NORTH BLVD. 
BETHLEHEM PA 18017 



FRANK RYBICKI 
COMPUTER ACTIVITY 
TEMPLE UNIVERSITY 
BROAD AND MONTGOMERY 
PHILADELPHIA PA 19122 



TERRY P. MEDLIN 

SCIENTIFIC RESEARCH UNIT - DPS A 
NATIONAL INSTITUTE OF DENTAL HEALTH 
BETHESDA MD 20014 



ATTENTION: RUTH DROZIN 
FREAS-ROOKE COMPUTER CENTER 
BUCKNELL UNIVERSITY 
LEWISBURG PA 17837 
(717) 524-1436 



RANCE J. DELONG 
MORAVIAN COLLEGE 
BETHLEHEM PA 18018 



JOHN T. LYNCH 
BURROUGHS CORP. 
P.O. BOX 517 
PAOLl 



PA 19301 



WAYNE RASBAND 
BLDG 36 ROOM 2A-03 
NATIONAL INSTITUTES OF HEALTH 
BETHESDA MD 20014 
(301) 496-4957 
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DANIEL C. HYDE 
COMPUTER SCIENCE PROGRAM 
BUCKNELL UNIVERSITY 
LEWISBURG PA 17837 
(717) 524-1392 



MARILYN HOFFMAN 
531 W. UNION BLVD. 
BETHLEHEM PA 18018 
(215) 865-6937 



E. L. ROWE 

BURROUGHS CORP. 

BOX 517 

PAOLl PA 19301 

(215) 648-2218 



DAVID A. GOMBERG 

DEPT. OF MATH. STAT. AND COMP. SCI. 

AMERICAN UNIVERSITY 

MASSACHUSETTS & NEBRASKA AVES. 

WASHINGTON DC 20016 

(202) 686-2393 
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JOHN W. ADAMS 

DEPT. OF I.E. 

19 PACKARD LAB 

LEHIGH UNIV. 

BETHLEHEM PA 18015. 



DAVE ENGLANDER 
302 SUMMIT STREET 
BETHLEHEM PA 18015 
(215) 865-9027 



JOHN A. WEAVER 
2112 PENNSYLVANIA AVE. F-6 
BETHLEHEM PA 18018 
(215) 867-1085 



JOSEPH A. MEZZAROBA 
BOX 164 

E. GREENVILLE PA 18041 
(215) 691-7000 (OFFICE) 
(215) 679-9900 (HOME) 



JOHN D. EISENBERG 

COMPUTING. CENTRE 

SMITH HALL 

U OF DELAWARE 

NEWARK DE 19711 

(302) 738-8441 X57 (OFFICE) 

(302) 453-9059 (HOME) 

WILLIAM Q. GRAHAM 

COMPUTING CENTER 

U. OF DELAWARE 

13 SMITH HALL 

NEWARK DE 19711 

(302) 738-8441 



ARTHUR A. BROWN 
1101 NEW HAMPSHIRE AVE. 
WASHINGTON DC 20037 
(202) 785-0716 



NW APT. 1002 



PETER A. RIGSBEE 

CODE 5494 

NAVAL RESEARCH LABORATORY 

WASHINGTON DC 20375 

(202) 767-3181 
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THOMAS A. KEENAN • 

DIVISION OF MATHEMATICAL AND COMPUTER 

NATIONAL SCIENCE FOUNDATION 

WASHINGTON DC 20550 

(202) 632-7^46 



CAROL A. OGDIN 
SOFTWARE TECHNIQUE INC. 
100 POMMANDER WALK 
ALEXANDRIA VA 22314 
(703) 549-0646 



GREGORY J. WINTERHALTER 
DIGITAL COMMUNICATIONS 
135 TECHNOLOGY PARK 
NORCROSS GA 30092 
(404) 443-1400 



ATTN: DIRECTOR ~^ 

NORTHEAST REGIONAL DATA CENTER ^ 

253 SSRB °° 

U OF FLORIDA <""> 

GAINESVILLE FL 32611 2> 

(904) 392-2061 r~ 



SHMUEL PELEG 

COMPUTER SCIENCE CENTER 

U OF MARYLAND 

COLLEGE PARK MD 20742 



BEN SHNEIDERMAN 

DEPT. OF INFO. SYS. MGMT. 

U OF MARYLAND 

COLLEGE PARK MD 20742 



ATTN: J. F. MCINTYRE - LIBRARIAN 

COMPUTING CENTER 

GILMER HALL 

U OF VIRGINIA 

CHARLOTTE SV I L VA 22903 

(804) 924-3731 



STEPHEN J. HARTLEY 
113 FERNCLIFF DR. 
WILLIAMSBURG VA 23185 
(804) 229-0337 (HOME) 
(804) 827-2897 (WORK) 



ATTENTION: JERRY W. SEGERS 
OFFICE OF COMPUTING SERVICES 
GEORGIA INSTITUTE OF TECHNOLOGY 
ATLANTA GA 30332 
(404) 894-4676 



GERALD N. CEDERQUIST 

ELECTRONICS RESEARCH BLDG 

EES STL/ASD 

GEORGIA INSTITUTE OF TECHNOLOGY 

ATLANTA GA 30332 

(404) 894-3417 



ATTN: LIBRARIAN 
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FRED L. SCOTT 


^o 


BROWARD COMMUNITY COLLEGE 




3501 DAVIE ROAD 


=& 


FT. LAUDERDAL FL 33314 


cr> 


(305) 581-8700 





JACOB C. Y. WU 
SYSTEM SCIENCES DIVISION 
COMPUTER SCIENCES CORPORATION 
8728 COLESVILLE ROAD 
SILVER SPRING MD 20910 
(301) 589-1545 X276 



RAINER F. MCCOWN 
MCCOWN COMPUTER SERVICES 
9537 LONG LOOK LANE 
COLUMBIA MD 21045 



ANN D. DAVIES 

UNIVERSITY COMPUTER CENTER 

VIRGINIA COMMONWEALTH UNIVERSITY 

1015 FLOYD AVE. 

RICHMOND VA 23284 

(804) 770-6339 



DAVID A. HOUGH 
529 HELM DRIVE 
NEWPORT NEWS VA 23602 
(804) 874-3387 



PHILLIP H. ENSLOW JR. 

SCHOOL OF INFO. AND COMP. SCI 

GEORGIA TECH 

ATLANTA GA 30332 

(404) 894-3152 



JAMES N. FARMER 

OFFICE OF COMPUTING SERVICES 

GEORGIA TECH 

225 NORTH AVE. NW 

ATLANTA GA 30332 

(404) 894-4660 



DONALD B. CROUCH 
DEPT. OF COMPUTER SCIENCE 
U. OF ALABAMA 
P.O. BOX 6316 
UNIVERSITY AL 35486 
(205) 348-6363 



PHILIP N. BERGESTESSER 
128 JACKSON AVE. 
MADISON AL 35758 
(205) 837-2400 
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JOE C. ROBERTS 
613 MARKET STREET 
POCOMOKE CITY MD 21851 
(804) 824-3411 X641 



J. C. KNIGHT 

LANGLEY RESEARCH CENTER 

M/S 125A 

NASA 

HAMPTON VA 23665 



JOHN J. GODA JR. ATTENTION: DAVID MADISON 

SCHOOL OF INFORMATION AND COMPUTER SCI ADVANCED SOFTWARE TECHNOLOGY DEPT. 






GEORGIA TECH 

ATLANTA GA 30332 

(404) 894-3131 



TEXAS INSTRUMENTS INC. 
304 WYNN DRIVE 
HUNTSVILLE AL 35806 
(205) 837-7510 



ANDREW S. PUCHRIK 
11623 CHARTER OAKS #202 
RESTON VA 22090 



FRED W. POWELL 
COMPUTER CENTER 
MARY BALDWIN COLLEGE 
STAUNTON VA 24401 
(703) 885-0811 



JOHN P. WEST 

OFFICE OF COMPUTING SERVICES 

GEORGIA TECH 

225 NORTH AVE. N.W. 

ATLANTA GA 30332 

(404) 894-4676 



SAMUEL T. BAKER 
1310 STONEWALL BLVD. 
MURFREESBORO TN 37130 
(615) 896-3362 (HOME) 
(615) 741-3531 (OFFICE) 



FRANK BREWSTER 
4701 KENMORE AVE #1009 
ALEXANDRIA VA 22304 
(703) 370-6645 



STEVEN M. BELLOVIN 
DEPT. OF COMP. SCI . 
U OF NORTH CAROLINA 
CHAPEL HILL NC 27514 
(919) 933-5698 



T. P. BAKER 

DEPT. OF MATH 

225 LOVE BUILDING 

FLORIDA STATE U 

TALLAHASSEE FL 32304 

(904) 644-2580 



ATTENTION: GORDON R. SHERMAN 

COMPUTER CENTER 

200 STOKELY MGMT. CENTER 

U OF TENNESSEE 

KNOXVILLE TN 37916 
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CHARLES PFLEEGER 
COMP. SCI . DEPT. 
U OF TENNESSEE 
KNOXVILLE TN 37916 
(615) 974-5067 



E. C. ZIMMERMAN 
COMPUTER CENTER 
THE COLLEGE OF WOOSTER 
WOOSTER OH 44691 
(216) 264-1234 X304 



DAVID S. WISE 

101 LINDLEY HALL 

INDIANA U 

GLOQMINGTON IN 47401 

(812) 337-4866 



RONALD G. MOSIER 
17596 WILDEMERE 
DETROIT Ml 48221 
(313) 956-2417 
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ATTN: DEPT. OF COMPUTER SCIENCE 
U OF MISSISSIPPI 
UNIVERSITY MS 38677 



PATRICIA VAN DERZEE 
PROCESS CONTROLS DIVISION 
CINCINNATI MILACRON INC. 
LEBANON OH 45036 
(513) 494-5320 



STEPHEN W. YOUNG 
WRUBEL COMPUTER CENTER 
HPER BUILDING 
INDIANA UNIVERSITY 
BLOOM.INGTON IN 47401 
(812) 337-1911 



R. NEIL FA I MAN JR. 

8235 APPOLINE 

DETROIT Ml 48228 



GAY THOMAS 

COMPUTER SCIENCE DEPT. 

DRAWER CC 

MISS. STATE MS 39762 

(601) 325-2942 



ROBERT J. SNYDER 

GR.FL. UNION BUILDING DATA CENTER 
INDIANA U - PURDUE- U AT INDIANAPOLIS 
1100 WEST MICHIGAN STREET 
INDIANAPOLIS IN 46202 



JAMES R. MILLER 
425-21 SOUTH RIVER ROAD 
W. LAFAYETTE IN 47906 
(317) 494-8232 (OFFICE) 



MARK HERSEY 

323 VILLAGE DRIVE APT. 534 
EAST LANSING Ml 48823 
(517) 351-5703 (HOME) 
(517) 355-1764 (OFFICE) 



CD 



LAVINE THRAILKILL 
COMPUTING CENTER 
U OF KENTUCKY 
LEXINGTON KY 40506 
(606) 258-2916 



ROY F. REEVES 
1640 SUSSEX COURT 
COLUMBUS OH 43220 
(614) 422-4843 



ATTN: DOCUMENTS ROOM LIBRARIAN 

COMPUTING CENTER 

U OF NOTRE DAME 

NOTRE DAME IN 46637 

(219) 283-7784 



DOUGLAS H. QUEBBEMAN 
2235 LOMBARDY DRIVE 
JEFFERSONVILL IN 47130 
(812) 945-2731 



EDWARD F.- GEHRINGER 
DEPT. OF COMPUTER SCIENCE 
MATH SCIENCES BUILDING 
PURDUE UNIVERSITY 
LAFAYETTE IN 47907 



JOSEPH H. FASEL I II 

COMPUTER SCIENCES 

442 MATH SCIENCES BUILDING 

PURDUE UNIVERSITY 

W. LAFAYETTE IN 47907 

(317) 494-8566 



THOMAS C. SOCOLOFSKY 
SYSTEMS RESEARCH INC 
241 E. SAGINAW 
EAST LANSING Ml 48823 
(517) 351-2530 (OFFICE) 
(517) 351^2530 (HOME) 



JOHN B. EULENBERG 
COMP. SCI. DEPT. 
MICHIGAN STATE U 
EAST LANSING Ml 48824 
(517) 353-0831 
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R. B. LAKE 
BIOMETRY 
WEARN BUILDING 
UNIVERSITY HOSPITALS 
CLEVELAND OH 44106 
(216) 791-7300 



GEORGE COHN I I I 
316 N. WASHINGTON 
BLOOMINGTON IN 47401 
(812) 337-9255 
(812) 337-1911 



ALAN A. KORTESOJA 

701 W. DAVIS 

ANN ARBOR Ml 48103 

(313) 995-6124 

(313) 995-6000 



STEVEN L. HUYSER 
COMPUTER LABORATORY 
MICHIGAN STATE U 
EAST LANSING Ml 48824 
(517) 353-1800 



CO 

en 



T. S. HEINES 

DEPT. OF COMPUTER SCIENCE 

CLEVELAND STATE UNIVERSITY 

CLEVELAND OH 44115 

(216) 687-4762 

(216) 687-4760 



HAL STEIN 

BOX 102 WRIGHT QUAD 
INDIANA UNIVERSITY 
BLOOMINGTON IN 47401 
(812) 337-7081 



L. RICHARD LEWIS 
5806 COOLIDGE ROAD ' '" 
DEARBORN Ml 48127 
(313) 274-6871 



MARK RIORDAN 
USER SERVICES 
COMPUTER LABORATORY 
MICHIGAN STATE UNIVERSITY 
EAST LANSING Ml 48824 
(517) 353-1800 



ROBERT L. BRIECHLE 
THE COMPUTER CENTER 
U OF AKRON 
302 E. BUCHTEL AVE. 
AKRON OH 44325 
(216) 375-7172 



ALFRED I. TOWELL 
WRUBEL COMPUTER CENTER 
INDIANA UNIVERSITY 
BLOOMINGTON IN 47401 
(812) 337-1911 



WILLIAM GROSKY 

MATH DEPT - COMP. SCI. SECTION 
WAYNE STATE UNIVERSITY 
DETROIT Ml 48202 



H. G. HEDGES 

DEPT. OF COMP. SCI. 

MICHIGAN STATE U 

E. LANSING Ml 48824 

(517) 353-6484 
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GORDON A. STEGINK 
COMPUTER CENTER 
325 MANITOU HALL 
GRAND VALLEY STATE COLLEGE 
ALLENDALE Ml 49401 
(616) 895-6611 X571 



CHARLES N. FISCHER 

MACC 

U OF WISCONSIN 

1210 WEST DAYTON ST. 

M.ADISON Wl 53706 

(608) 262-7870 



GLENN MILLER 

2317 N. HENRY ST. 

N. ST. PAUL MN 55109 

(612) 777-2483 



PAUL CHR I STOPHERSON 
M.S. MN11-1611 
HONEYWELL INC. 
600 SECOND STREET N. 
HOPKINS MN 55343 
(612) 542-6438 



CO 
c— > 
3> 



GEORGE 0. STRAWN 

DEPT. OF COMPUTER SCIENCE 

IOWA STATE U 

AMES I A 50011 

(515) 294-2259 



FRANK H. HORN 

ACADEMIC COMPUTER CENTER 

U OF WISCONSIN 

1210 WEST DAYTON STREET 

MADISON Wi 53706 

(608) 262-9841 



MARK RUST AD 

525 HARRIET AVE #213 

ST. PAUL MN 55112 



MARK BILODEAU 

ENGINEERING SYSTEMS 4TH FLOOR 

NORTHERN STATES POWER 

414 NICOLLET MALL 

MINNEAPOLIS MN 55401 

(612) 330-6749 

(612) 330-5899 
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ATTN: SERIALS DEPT. 
UNIVERSITY LIBRARIES 
UNIVERSITY OF IOWA 
IOWA CITY IA 52242 



ED GLASER 

COMPUTING SERVICES 

U OF WISCONSIN - GREEN BAY 

GREEN BAY Wi 54302 

(414) 465-2309 



ROBERT D. VAVRA 
741 TERRACE DRIVE 
ROSEVILLE MN 55113 
(612) 483-6123 



CHRIS EASTLUND 

ENGINEERING SYSTEMS 4TH FLOOR 

NORTHERN STATES POWER 

414 NICOLLET MALL 

MINNEAPOLIS MN 55401 

(612) 330-6749 

(612) 330-5899 
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ATTN: UCC LIBRARIAN 

UNIVERSITY COMPUTER CENTER 

LCM 

UNIVERSITY OF IOWA 

IOWA CITY IA 52242 

(319) 353-3170 



DAVID A. NUESSE 

DEPARTMENT OF COMPUTER SCIENCE 

U OF WISCONSIN - EAU CLAIRE 

EAU CLAIRE WI 54701 

(715) 836-2526 



STEVE M. WEINGART 

MS 4953 

SPERRY-UNIVAC 

2276 HIGHCREST DRIVE 

ROSEVILLE MN 55113 



JOHN URBAN SKI 
1929 FREMONT AVE. S. APT. 
MINNEAPOLIS MN 55403 
(612) 377-3198 
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W. A; HINTON 

SAN W 570 C 

U OF WISCONSIN - MILWAUKEE 

P.O. BOX 413 

MILWAUKEE WI 53201 

(414) 963-4005 



BROOKS DAVID SMITH 
4473 N. NEWHALL ST. 
SHORE WOOD WI 53211 
(414) 332-6646 



RUDOLPH C. POLENZ PETER H. ZECHME I STER 

INFORMATION SYSTEMS AND COMPUTING SERV 926 W. MONTANA AVE. 
U OF WISCONSIN - EAU CLAIRE ST. PAUL MN 55117 

EAU CLAIRE WI 54701 (612) 489-5166 

(715) 836-4428 



BRUCE A. PUMPLIN 
DEPT OF COMPUTER SCIENCE 
U OF WISCONSIN - EAU CLAIRE 
EAU CLAIRE WI 54701 
(715) 836-2315 



ATTENTION: ROBERT E. NOVAK 
DSPL DEVELOPMENT GROUP 
SPERRY UN I VAC 

UNI VAC PARK /P.O. BOX 3525 
ST. PAUL MN 55165 
(612) 456-5551 



SCOTT BERTILSON 
2929 42ND AVE. S. 
MINNEAPOLIS MN 55406 
(612) 729-0059 



INDULIS VALTERS 
2810 E 22ND AVE. 
MINNEAPOLIS MN 55406 
(612) 341-4430 
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HERMAN BERG 

108 E. DAYTON STREET 

MADISON WI 53703 



CARL HENRY 
COMPUTER CENTER 
CARLETON COLLEGE 
NORTHFIELD MN 55057 
(507) 645-4431 X504 



LEO J. SLECHTA 

DSD 

SPERRY UN I VAC 

BOX 3525 MS U1U25 

ST. PAUL MN 55165 

(612) 456-2743 



DON HAMNES 

4215 PLEASANT AVE. SO. 
MINNEAPOLIS MN 55409 
(612) 823-3030 



ATTN: FRIEDA S. COHEN 
ACADEMIC COMPUTING CENTER 
U OF WISCONSIN 
1210 W. DAYTON ST. 
MADISON Wi 53706 



TIMOTHY W. HOEL 
ACADEMIC COMPUTER CENTER 
ST. OLAF COLLEGE 
NORTHFIELD MN 55057 
(507) 663-3096 



DAVID HELFINSTINE 
1136 5TH AVENUE SOUTH 
ANOKA MN 55303 
(612) 421-8964 



JOHN FUNG 

425 13TH AVE S.E. #406 
MINNEAPOLIS MN 55414 
(612) 376-5464 (OFFICE) 
(612) 378-0427 (HOME) 
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WALT PERKO 
727 15TH AVE. S.E. 
MINNEAPOLIS MN 55414 
(612) 331-6984 



TIM BONHAM 
D605/1630 S. 6TH ST. 
MINNEAPOLIS MN 55454 
(612) 339-4405 



JOHN T. E ASTON 

SSRFC 

25G BLEGEN HALL 

U OF MINNESOTA 

WEST BANK 

MINNEAPOLIS MN 55455 

(612) 373-9917 



TIMOTHY J. HOFFMANN 
364 FRONTIER HALL 
U OF MINNESOTA 
EAST BANK 

MINNEAPOLIS MN 55455 
(612) 373-6957 



o 
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GEOFF WATTLES 
407 ERIE STREET 
MINNEAPOLIS MN 55414 
(612) 331-7087 



R. K. NORDIN 

1615 SOUTH 4TH ST. APT.M3607 
MINNEAPOLIS MN 55454 
(612) 339-5232 (HOME) 
(612) 482-3751 (OFFICE) 



LINCOLN FETCHER 

UNIVERSITY COMPUTER CENTER 

227 EXPERIMENTAL ENGINEERING 

UNIVERSITY OF MINNESOTA 

MINNEAPOLIS MN 55455 

(612) 376-1637 



GEORGE D. J EL AT IS 

BOX 15 MAYO 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 373-8941 



KEITH HAUER-LOWE 
4819 COLUMBUS AVE. SO. 
MINNEAPOLIS MN 55417 
(612) 633-6170 X3362 (WORK) 
(612) 824-8026 (HOME) 



ATTENTION: PAUL C. SMITH 



KEVIN FJELSTED 



CONSULTING GROUP ON INSTRUCTIONAL DESI UNIVERSITY COMPUTER CENTER 



205 ELLIOTT HALL 
U OF MINNESOTA 
EAST BANK 

MINNEAPOLIS MN 55455 
(612) 373-5352 



227 EXP ENGR 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 373-4181 



DAN LALIBERTE 

UNIVERSITY COMPUTER CENTER 

227 EXP. ENGR. 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 373-4181 



at 



JONATHON R. GROSS 
DIGITAL EQUIPMENT CORP. 
8030 CEDAR AVENUE SOUTH 
MINNEAPOLIS MN 55420 
(612) 854-6562 



ATTENTION: STEVE RE I SMAN 

SCH. OF DENTISTRY/CLINICAL SYS. DIV. 

8-440 HEALTH SCIENCE UNIT A 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 376-4131 



K. FRANKOWSKI 

COMPUTER SCIENCE DEPARTMENT 

11 OH LIND HALL 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 373-7591 



LAWRENCE A. LIDDIARD 

UNIVERSITY COMPUTER CENTER 

227 EXP. ENG. BLDG. 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 373-5239 



ROBERT A. STRYK 
5441 HALIFAX LANE 
EDINA MN 55424 
(612) 920-5434 (HOME) 
(612) 887-4356 (OFFICE) 



RON THOMAS 

7725 WASHINGTON AVE. S. 
MINNEAPOLIS MN 55425 
(612) 941-6500 



ATTN: COMPUTER SCIENCE DEPT. 

114 LIND HALL 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 373-0132 



ATTN: REFERENCE ROOM 

UNIVERSITY COMPUTER CENTER 

227 EXP ENGR 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 373-7744 



KRISTINA GREACEN 

C.SCI. DEPT. 

114 LIND HALL 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 



JOEL M. HALPERN 

UNIVERSITY COMPUTER CENTER 

227 EXP. ENGR. 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 373-4181 



DENNIS R. LIENKE 

UNIVERSITY COMPUTER CENTER 

214 EXP. ENGR. 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 373-1572 

SHIHTA LIN 

UNIVERSITY COMPUTER CENTER 

227 EXP ENGR 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 373-4886 
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HUGO MEISSER 
3021 WISCONSIN AVE. N. 
MINNEAPOLIS MN 55427 
(612) 544-2349 



RANDALL W. WARREN 

HQS06B 

CONTROL DATA CORPORATIO 

P.O. BOX 

MINNEAPOLIS MN 55440 



KEN BORGENDALE 

C.SCI. DEPT. 

114 LIND HALL 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 824-3389 

JEFFREY J. DRUMMOND 

UNIVERSITY COMPUTER CENTER 

LAUDERDALE 

U OF MINNESOTA 

MINNEAPOLIS MN 55455 

(612) 373-4573 



BRIAN HANSON 

UNIVERSITY COMPUTER CENTER 

227 EXP. ENGR. 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 376-5262 (OFFICE) 

THE A D. HODGE 

UNIVERSITY COMPUTER CENTER 

227 EXP. ENGR. 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 373-4599 



JOHN E. LIND 

139 TERRITORIAL HALL 

UNIVERSITY OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 



MICHAEL ROBERT MEISSNER 
1541 PIONEER HALL 
U OF MINNESOTA 
EAST BANK 
MINNEAPOLIS MN 55455 



CD 



DAVID C. MESSER 

UNIVERSITY COMPUTER CENTER 

227 EXPERIMENTAL ENGINEERING 

UNIVERSITY OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 376-2787 



G. MICHAEL SCHNEIDER 

C.SCi . DEPT. 

114 LIND HALL 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 373-7582 



L. W. YOUNGREN 
1505 N.W. 41ST ST. APT. 18F 
ROCHESTER MN 55901 
(507) 285-9696 



ALBERT STEINER 
VOGELBACK COMPUTING CENTER 
NORTHWESTERN U 
2129 SHERIDAN ROAD 
EVANSTON IL 60201 
(312) 492-3682 
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ANDY MICKEL 

UNIVERSITY COMPUTER CENTER 

227 EXP. ENGR. 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 376-7290 



JOHN P. STRAIT 

UNIVERSITY COMPUTER CENTER 

227 EXP. ENGR. 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 376-7290 



JAMES F. MARTINSON 
1210 WILLMAR AVE 
WILLMAR MN 56201 
(612) 796-2342 



BRIT J. BARTTER 
850A FOREST AVENUE 
EVANSTON IL 60202 



JAMES F. MINER 

SSRFC 

25 BLEGEN HALL 

U OF MINNESOTA 

WEST BANK 

MINNEAPOLIS MN 55455 

(612) 373-9916 



BILL WOOD 

C.SCi. DEPT. 

114 LIND HALL 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 373-7746 



R. WARREN JOHNSON 
DEPT. OF MATH AND COMP . 
ST. CLOUD STATE U 
ST. CLOUD MN 56301 
(612) 255-2147 



SCI 



JONATHAN SACHS 

TRANS UNION SYSTEMS CORPORATION 

111 WEST JACKSON BLVD 

CHICAGO IL 60604 

(312) 431-3330 



CD 



JOHN NAUMAN , 

901 MIDDLEBROOK HALL 

U OF MINNESOTA 

WEST BANK 

MINNEAPOLIS MN 55455 

(612) 376-6596 



DAVID PERLMAN 

COMPUTER SCIENCE DEPARTMENT 

114 LIND HALL 

UNIVERSITY OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 373-7581 

HERBERT RUBENSTEIN 

UNIVERSITY COMPUTER CENTER 

227 EXP. ENGR. 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 373-4181 



ATTN: SSRFC LIBRARY 

SSRFC 

25 BLEGEN HALL 

U OF MINNESOTA 

WEST BANK 

MINNEPOLIS MN 55455 

(612) 373-5599 

MITCHELL R. JOELSON 

SSRFC 

25 BLEGEN HALL 

U OF MINNESOTA 

WEST BANK 

MPLS. MN 55455 

(512) 781-7323 (HOME) 

DAVID SARANEN 
117 7TH ST. SO. 
VIRGINIA MN 55792 
(218) 741-1378 



HAROLD DE VORE 
BOX 7161 UNIVERSITY STATION 
GRAND FORKS NO 58202 
(701) 746-6977 



R. I. JOHNSON 

COMP. SCI. DEPT. 

U OF NORTH DAKOTA 

BOX 181 UNIVERSITY STATION 

GRAND FORKS ND 58202 

(701) 777-4107 



GARY J. BOOS 
517 N. 7TH STREET 
BISMARK ND 58501 
(701) 223-0441 (WORK) 



DAVID E. CARLTON 
DEPT. OF INFO. SCI . 
NORTHEASTERN ILLINOIS U 
5500 N. ST. LOUIS AVE. 
CHICAGO IL 60625 



TED FISHMAN 

6049 KIMBALL 

CHICAGO IL 60659 



ATTN: CONSULTING OFFICE 
COMPUTING SERVICES OFFICE 
116 DIGITAL COMPUTER LAB 
U OF ILLINOIS 
URBANA IL 61801 
(217) 333-6133 
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TIMOTHY J SALO 

UNIVERSITY COMPUTER CENTER 

LAUDERDALE 

U OF MINNESOTA 

MINNEAPOLIS MN 55455 

(612) 376-5607 



ATTENTION: DAN BURROWS 

UMD COMPUTER CENTER 

178 M.W.ALWORTH HALL 

U OF MINNESOTA 

DULUTH 

DULUTH MN 55812 



ATTENTION: KYU LEE 
DEPARTMENT OF COMPUTER SCIENCE 
UNIVERSITY OF MONTANA 
MISSOULA MT 59801 
(406) 243-2883 



RICHARD BALOCCA 

114B DIGITAL COMPUTER LAB 

U OF ILLINOIS 

URBANA IL 61801 

(217) 344-5284 



BOB SCARLETT 

PHYSICS DEPT. 

148 PHYSICS 

U OF MINNESOTA 

EAST BANK 

MINNEAPOLIS MN 55455 

(612) 373-0243 



MARK LUKER 

MATH SCIENCES DEPT. 

U OF MINNESOTA 

DULUTH 

DULUTH . MN 55812 

(218) 726-8240 



MARK S. NIEMCZYK 
HEWITT ASSOCIATES 
102 WILMOT ROAD 
DEERFIELD IL 60015 
(312) 945-8000 



ROGER GULBRANSON 

PHYSICS DEPT. 

U OF ILLINOIS 

URBANA IL 61801 

(217) 367-8470 (HOME) 

(217) 333-3191 (OFFICE) 
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CHARLES HEDRICK 

183 COMMERCE WEST 

U OF ILLINOIS 

URBANA IL 61801 

(217) 333-4515 

(217) 356-8425 



DENNIS S. ANDREWS 
INFORMATION PROCESSING 
SOUTHERN ILLINOIS UNIVERSITY 
CARBONOALE IL 62901 



D. B. KILLEEN 
COMPUTER LAB 
RICHARDSON BLDG. 
TULANE UNIVERSITY 
NEW ORLEANS LA 70118 



JOHN NUNNALLY 

HARDING COLLEGE 

BOX 744 

SEARCY AR 72143 

(501) 268-6161 X257 
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M. D. MICKUNAS 

297 DCL 

U OF ILLINOIS 

URBANA I L 61801 

(217) 333-6351 



LARRY D. LAND IS 
UNITED COMPUTING SYSTEMS 
2525 WASHINGTON 
KANSAS CITY MO 64108 
(816) 942-6063 



FREDERICK A. HOSCH 
COMPUTER RESEARCH CENTER 
U OF NEW ORLEANS 
NEW ORLEANS LA 70122 



RICHARD V. ANDRE E 
MATH DEPT. 
U OF OKLAHOMA 
NORMAN OK 73019 
(405) 325-3410 
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CARLTON MILLS 
MILLS INTERNATIONAL 
203 NORTH GREGORY 
URBANA IL 61801 
(217) 328-2436 (HOME) 
(217) 333-6971 



JEFFERY M. RAZAFSKY 

UNITED COMPUTING SYSTEMS INC. 

500 W. 26TH STREET 

KANSAS CITY MO 64108 

(816) 221-9700 



WARREN JOHNSON 
U OF SOUTHWESTERN LOUISIANA 
BOX 4-2770 USL STATION 
LAFAYETTE LA 70504 
(318) 234-7349 



RALPH HOWENSTINE 
2313 CRESTMONT #208 
NORMAN OK 73069 



CD. 



ATTN: RECEIVING CLERK 
CERL - SOC 
U.S. ARMY 
P.O. BOX 4005 
CHAMPAIGN IL 61820 
(217) 352-6511 



FRED P. BAKER 
302 E. GREGORY 
CHAMPAIGN IL 61820 
(217) 344-7511 



HOWARD D. PYRON 
MATH - C.SCI . 
U OF MISSOURI - ROLLA 
ROLLA MO 65401 
(314) 341-4491 



STEVEN S. MUCHNICK 

DEPARTMENT OF COMPUTER SCIENCE 

U OF KANSAS 

LAWRENCE KS 66045 



ED KATZ 

COMPUTER SCIENCE DEPT. 

U OF SOUTHWESTERN LOUISIANA 

BOX 4-4330 USL STATION 

LAFAYETTE LA 70504 



STEVE LANDRY 

COMPUTER CENTER 

U OF SOUTHWESTERN LOUISIANA 

P.O. BOX 4-2770 

LAFAYETTE LA 70504 

(318) 234-7349 



STEPHEN A. PITTS 
305 EAST JARMAN DRIVE 
MIDWEST CITY OK 73110 
(405) 732-4060 



GILBERT J. HANSEN 
3104 BONNIEBROQK DRIVE 
PLANO TX 75075 
(214) 423-7837 
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AVRUM ITZKOWITZ 
505 E. CLARK APT. 22 
CHAMPAIGN IL 61820 
(217) 359-9644 (HOME) 
(217) 352-6511 (WORK) 



LYNNE J. BALDWIN 

DEPT. OF MATH/COMP. SCI. 

U OF NEBRASKA 

BOX 688 

OMAHA NE 68101 

(402) 554-2836 



DAVID LANDSKOV 

U OF SOUTHWESTERN LOUISIANA 

USL BOX 4-4154 

LAFAYETTE LA 70504 

(318) 234-7640 



BRIAN W. JOHNSON 
1525 WESTLAKE 
PLANO TX 75075 
(214) 690-2885 
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DANIEL M. O'BRIEN 
601 E. CLARK #10 
CHAMPAIGN I L 61820 
(217) 356-2718 



TERRY E. WEYMOUTH 
C/O J.W.WEYMOUTH 
6110 MEADOWBROOK LANE 
LINCOLN NE 68510 



A. I. STOCKS 

P.O. BOX 4-1039 

USL STATION 

LAFAYETTE LA 70504 

(318) 233-3850 X538 



DENNIS J. FRAILEY 
COMP. SCI. DEPT. 
SOUTHERN METHODIST UNIV. 
DALLAS TX 75222 



JACK THOMPSON 

MID. ILLINOIS COMPUTER CO-OP 
COTTONWOOD ROAD 
EDWARDSVILLE IL 62025 
(618) 288-7268 



SHARAD C. SETH 
DEPT. OF COMP. SCI. 
U OF NEBRASKA 
LINCOLN NE 68588 
(402) 472-3488 



TERRY M. WALKER 
COMPUTER SCIENCE DEPT. 
U OF SOUTHWESTERN LOUISIANA 
P.O. BOX 4-4330 
LAFAYETTE LA 70504 
(318) 234-7640 



W. J. MEYERS 
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DALLAS TX 75243 
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(214) 231-4869 
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GARY CEDERQUiST 
SOUTHERN METHODIST UNIV. 
30X 2112 
DALLAS TX 75275 



RICHARD HUBER 

DEPT. OF INDUSTRIAL ENGINEERING 

TEXAS A&M UNIVERSITY 

COLL. STATION TX 77843 

(713) 845-5531 X256 



WILLIAM L. COHAGAN 
SUITE 211 

S/B/P & C ASSOCIATES 
8705 SHOAL CREEK BLVD. 
AUSTIN TX 78758 
(512) 458-2276 



WILLIAM M. WA1TE 
ELECTRICAL ENGINEERING DEPT. 
SOFTWARE ENGINEERING GROUP 
UNIVERSITY OF COLORADO 
BOULDER CO 80302 
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JANET TAYLOR 
USER SERVICES 
COMPUTING LABORATORY 
SOUTHERN METHODIST UNIVERSITY 
DALLAS TX 75275 
(214) 692-2900 



MIKE GREEN 

DATAPQINT CORPORATION 
9725 DATAPOINT DRIVE 
SAN ANTONIO TX 78284 
(512) 690-7345 



HARRY P. HAIDUK 

DEPT. OF COMP. INFO. SYSTEMS 

WEST TEXAS STATE U 

CANYON TX 79015 

(806) 656-3966 



LLOYD D. FOSDICK 

DEPARTMENT OF COMPUTER SCIENCE 

ECOT 7-7 

U OF COLORADO 

BOULDER CO 80309 

(303) 492-7514 
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JESSE D. MIXON 
DEPT. OF COMPUTER SCIENCE 
STEPHEN F. AUSTIN STATE U 
P.O. BOX 6167 SFA STATION 
NACOGDOCHES TX 75961 
(713) 569-2508 



WILLETT KEMPTON 
2512 SAN GABRIEL ST. 
AUSTIN TX 78705 



MAURICE BALLEW 
COMPUTER SERVICES 
TEXAS TECH UNIVERSITY 
BOX 4519 

LUBBOCK TX 79409 
(806) 742-2900 



GEORGE H. RICHMOND 
COMPUTING CENTER 
UNIVERSITY OF COLORADO 
3645 MARINE STREET 
BOULDER CO 80309 
(303) 492-6934 
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GINGER KELLY 

ICSA 

RICE UNIVERSITY 

HOUSTON TX 77001 

(713) 527-.... 



JOHN EARL CRIDER 
7201 BROMPTON ROAD #A114 
HOUSTON TX 77025 
(713) 665-3016 



JAMES A. KENDALL 

MHMR/TRIMS 

TEXAS MEDICAL CENTER 

HOUSTON TX 77030 

(713) 797-1976 



ATTN: DOROTHY SMITH- REFERENCE LIBRAR LEONARD H. WEINER 



COMPUTATION CENTER 
U OF TEXAS AUSTIN 
AUSTIN TX 78712 
(512) 471-3242 



WILHELM BURGER 

DEPT. OF COMPUTER SCIENCES 

328 PAINTER HALL 

U OF TEXAS AUSTIN 

AUSTIN TX 78712 

(512) 471-4088 

(512) 471-7316 

WAYNE SEIPEL 
COMPUTATION CENTER 
U OF TEXAS 
AUSTIN TX 78712 



DEPT. OF MATH AND COMP. SCI. 

TEXAS TECH. U 

P.O. BOX 4319 

LUBBOCK TX 79409 

(806) 742-2571 



D. A. CAUGHFIELD 
609 E. N. 21 ST 
ABILENE TX 79601 
(915) 672-1604 



RICHARD TAYLOR 
2425 RALEIGH ST. 
DENVER CO 80212 
(303) 477-7995 



ATTN: USER SERVICES GROUP 
UNIVERSITY COMPUTER CENTER 
COLORADO STATE U 
FORT COLLINS CO 80523 
(303) 491-5133 



DALE H. GRIT 

DEPARTMENT OF COMPUTER SCIENCE 

COLORADO STATE U 

FT. COLLINS CO 80523 

(303) 491-7033 



ATTN: B1700 PROTEUS PROJECT 

COMPUTER SCIENCE DEPT. 

3160 MEB 

U OF UTAH 

SALT LAKE CIT UT 84112 

(801) 581-8224 
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SCOTT K. WARREN 
ROSETTA ALGORITHMS 
2414 BRANARD #D 
HOUSTON TX 77098 



WALLY WEDEL 
COMPUTATION CENTER 
U OF TEXAS AUSTIN 
AUSTIN TX 78712 
(512) 471-3242 



ATTN: LIBRARY 

67 DENVER FEDERAL CENTER 
BUREAU OF RECLAMATION 
DENVER CO 80225 



MARTIN L GRISS 
COMPUTER SCIENCE DEPT 
U OF UTAH 

SALT LAKE CIT UT 84112 
(801) 581-6542 



RUSSELL W ZEARS 

BIOMETRY LAB 

449 ADMINISTRATION BLDG R7 

UNIVERSITY OF TEXAS MEDICAL BRANCH 

GALVESTON TX 77550 

(713). 765-1813 



DAVID W. HOGAN 

4104 AVENUE F 

AUSTIN TX 78751 



HOWARD BUSSEY JR. M. A. KLE INERT 

NATIONAL OCEANIC AND ATMOSPHERIC ADMIN COMP. SCI. DEPT. 

BLDG. 1 RM 4557 3160 MERRILL ENG. BLDG. 

U.S. DEPARTMENT OF COMMERCE U OF UTAH 

BOULDER CO 80302 SALT LAKE CIT UT 84112 






ED SHARP 

COMPUTER CENTER 

U OF UTAH 

SALT LAKE CIT UT 34112' 

(801) 581-6802 



BILL BUZBEE 

LOS ALAMOS SCIENTIFIC LABORATORY 

C-DO MS-260 

UNIVERSITY OF CALIFORNIA 

P.O. BOX 1663 

LOS ALAMOS NM 87545 



ATTN: PROGRAMMING ADVISOR 

UNS COMPUTING CENTER 

22 WR 

U OF NEVADA 

RENO NV 39507 



MICHAEL TEENER 
TECHNOLOGY SERVICE CORP. 
2811 WILSHIRE BLVD. 
SANTA MONICA CA 90403 
(213) 829-7411 X244 



CO 

3> 



THEODORE A. NORMAN 
COMP. SCI. DEPT. 
BRIGHAM YOUNG UNIVERSITY 
PROVO UT 84602 
(801) 374-1211 X3027 



ROBERT T. JOHNSON 

C-11 MAIL STOP 296 

LOS ALAMOS SCIENTIFIC LABORATORY 

P.O. BOX 1663 

LOS ALAMOS NM 87545 

(505) 667-5014 



GARY CARTER 

SEISMOLOGY DEPT. 

MACK AY SCHOOL OF MINES 

U OF NEVADA RENO 

RENO NV 89507 



PHYLLIS A. RE ILLY 
19711 GALWAY AVENUE 
CARSON CA 90746 
(213) 321-5215 



RICHARD OHRAN 

ELECTICAL ENGINEERING DEPT 

459 ESTB 

BRIGHAM YOUNG UNIVERSITY 

PROVO UT 84602 

(801) 374-1211 X4012 



JOHN MONTAGUE 

GROUP C1 1 

MAIL STOP 296 

LOS ALAMOS SCIENTIFIC LABORATORY 

LOS ALAMOS NM 87545 



ATTN: ACADEMIC SERVICES 
UNIVERSITY COMPUTER CENTER 
U OF SOUTHERN CALIFORNIA 
1020 W. JEFFERSON BLVD. 
LOS ANGELES CA 90007 
(213) 746-2957 



PAUL L. MCCULLOUGH 
911 GENOA ST. 
MONROVIA CA 91016 
(213) 447-3202 



CD 



PATRICK PECORARO 
UNIVERSITY COMPUTER CENTER 
U OF ARIZONA 
TUCSON AZ 85721 
(602) 884-2901 



JAMES DARLING 

NEW MEXICO TECH 

BOX 2139 CAMPUS STATION 

SOCORRO NM 87801 

(505) 835-5374 



STEVEN BARRYTE 
6620 W. 5TH STREET 
LOS ANGELES CA 90048 
(213) 653-8697 



CLARK M. ROBERTS 
219 VIOLET AVENUE 
MONROVIA CA 91016 
(213) 456-3858 (HOME) 
(213) 658r2405 (WORK) 



R. W. MILKEY 

KITT PEAK NATIONAL OBSERVATORY 

P.O. BOX 26732 

TUCSON AZ 85726 

(602) 327-5511 



TOM SANDERSON 
617 NORTH FOURTH 
BELEN ' NM 87002 



T. A. NARTKER ERWIN BOOK 

NEW MEXICO INSTITUTE OF MINING AND TEC 3169 COLBY AVENUE 
SOCORRO NM 87801 LOS ANGELES CA 90066 

(505) 835-5126 



J. MACK ADAMS 

COMP. SCI . DEPT. 

NEW MEXICO STATE U 

BOX 3CU 

LAS CRUCES NM 88003 

(505) 646-3723 



HOWARD H. METCALF 
2590 GLEN GREEN #4 
HOLLYWOOD CA 90068 



CHARLES L. LAWSON 

JET PROPULSION LABORATORY 

MS 125/128 

CALIFORNIA INSTITUTE OF TECHNOLOGY 

4800 OAK GROVE DR. 

PASADENA CA 91103 

(213) 354-4321 

WILLIAM C. PRICE 
480 PEMBROOK DRIVE 
PASADENA CA 91107 
(213) 351-6551 X219 



m 



en 



NANCY RUIZ 
ORG. 5166 
SAND I A LABS 

ALBUQUERQUE NM 87115 
(505) 264-3690 



ATTN: USER SERVICES LIBRARIAN 
UNIVERSITY COMPUTER CENTER 
NEW MEXICO STATE UNIVERSITY 
BOX 3AT 

LAS CRUCES NM 88003 
(505) 644-4433 



DENNIS HEIMBIGNER , 
2500 CARNEGIE LANE #B 
REDONDO BEACH CA 90278 
(213) 374-9936 



GERALD BRYAN 
SEAVER COMPUTER CENTER 
CLAREMONT COLLEGES 
CLAREMONT CA 91711 
(714) 626-8511 X3228 



HARRY M. MURPHY JR. 
AIR FORCE WEAPONS LABORATORY 
KIRTLAND AFB NM 87117 
(505) 264-9317 



JOHN WERTH 

DEPT. OF MATH 

U OF NEVADA LAS VEGAS 

LAS VEGAS NV 89154 

(702) 739-3715 



RALPH L. LONDON 

INFORMATION SCIENCES INSTITUTE 

U OF SOUTHERN CALIFORNIA 

4676 ADMIRALTY WAY 

MARINA DEL RA CA 90291 



MARK J, KAUFMAN 
916 E WASHINGTON APT. 108 
ESCONOIDO CA 92025 
(714) 743-5911 
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en 
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MARK OVERGAARD 

APIS DEPT. 

C-014 

U OF CALIFORNIA - SAN DIEGO 

LA JOLLA CA 92093 

(714) 452-2728 



ATTENTION: EDWARD E. BALKOVICH 
SCIENCE AND TECHNOLOGY DIVISION 
GENERAL RESEARCH CORP. 
5383 HOLL1STER AVE. 
SANTA BARBARA CA 93105 
(805) 964-7724 



DENNIS GRAHAM 

AMDAHL CORP. 

1250 E. ARGUES AVE. 

SUNNYVALE CA 94086 

(408) 735-4602 



JOHN C. BEATTY 

L-73 

LAWRENCE LIVERMORE LAB 

BOX 808 

LIVERMORE CA 94550 

(415) 447-1100 X3114 



-a 

CO 



MICHAEL S. BALL 
CODE 2 

NAVAL UNDERSEA CENTER 
SAN DIEGO CA 92132 



ATTN: COMPUTER SCIENCES INSTITUTE 
U OF CALIFORNIA 
RIVERSIDE CA 92507 



ROBERT ALAN DOLAN 

SPEECH COMMUNICATIONS RESEARCH LAB 

800A MIRAMONTE DRIVE 

SANTA BARBARA CA 93109 

(805) 965-3011 



NEIL W. WEBRE 

DEPT. OF COMP. SCI. AND STAT. 
CALIF. POLY. STATE UNIV. 
SAN LUIS OBIS CA 93401 
(805) 546-2986 



M. H. MACDOUGALL 
AMDAHL CORP. 
1250 EAST ARQUES AVE. 
SUNNYVALE CA 94086 
(408) 736-4856 



GARY W. WtNIGER 
P.O. BOX 60835 
SUNNYVALE CA 94088 
(415) 964-6982 



WILLIAM P. TAYLOR 

L-315 

UNIVERSITY OF CALIFORNIA 

P.O. BOX 808 

LIVERMORE CA 94550 

(415) 455-6729 



BRYAN L. HIGGINS 
SCIENCE APPLICATIONS INC. 
8201 CAPWELL DRIVE 
OAKLAND CA 94621 
(415) 562-9163 



CO 

f— 

m 



rn 



KURT COCKRUM 

3398 UTAH 

RIVERSIDE CA 92507 



JAMES L. BEUG 
DEPT. OF COMP. SCI . 
CALIFORNIA POLYTECHNIC STATE U 
SAN LUIS OBIS CA 93407 
(805) 546-1255 



NIKLAUS WIRTH 
XEROX RESEARCH CENTER 
3333 COYOTE HILL ROAD 
PALO ALTO CA 94304 



JEFFREY BARTH 
COMP. SCI. DIVISION 
573 EVANS HALL 
U OF CALIFORNIA 
BERKELEY CA 94720 
(415) 642-4948 



JOHN M. GRAM 
COMPUTING FACILITY 
U OF CALIFORNIA 
IRVINE CA 92717 
(714) 833-6844 



GARY BABCOCK 
110-E RICHMOND ROAD 
CHINA LAKE CA 93555 
(714) 446-6733 



JON F. HUERAS DAVID ELLIOT SHAW 

DEPT. OF INFORMATION AND COMPUTER SCIE STRUCTURED SYSTEMS 
U OF CALIFORNIA IRVINE 200 THIRD STREET -SUITE 207 

IRVINE CA 92717 LOS ALTOS CA 94022 

(415) 966-2082 
(415) 948-0877 



PAUL HECKEL 

INTERACTIVE SYSTEMS CONSULTANTS 
P.O. BOX 2345 
PALO ALTO CA 94305 
(415) 965-0237 



JOHN BANNING 

MAIL DROP 88 

STANFORD LINEAR ACCELERATOR CENTER 

P.O.BOX 4349 

STANFORD CA 94305 

(415) 854-3300 X2802 (OFFICE) 

(415) 325-9226 (HOME) 



BLAND EW1NG 
DEPT. OF ENTYMOLOGY 
137 G I ANN INI HALL 
U OF CALIFORNIA 
BERKELEY CA 94720 
(415) 642-6660 



ED FOURT 

C/0 LBL LIBRARY 

134 BLDG 50 

LAWRENCE BERKELEY LAB 

BERKELEY CA 94720 

(415) 843-2740 X5293 



CD 

en 



WILLIAM L. COOPER 
ORG 4400 

INTERSTATE ELECTRONICS 
707 E. VERMONT 
ANAHEIM CA 92805 
(714) 772-2811 



APRIL MILLER CONVERSE 

SEISMIC ENGINEERING BRANCH 

U.S.G.S. 

345 MIDDLEFIELD ROAD 

MENLO PARK - CA 94025 



DAVID C. LUCKHAM 
COMP. SCI. DEPT. 
A . I . LABORATORY 
STANFORD UNIVERSITY 
STANFORD CA 94305 
(415) 497-4971 



SUSAN L. GRAHAM 

COMP. SCI. DIVISION-EECS 

511 EVANS HALL 

U OF CALIFORNIA 

BERKELEY CA 94720 



DAVID W. GIEDT 
5421 WILLOWICK CIR. 
ANAHEIM CA 92807 
(714) 772-2811 



GLENN T. EDENS 

DACONICS DIV. 

XEROX 

350 POTRERO AVENUE 

SUNNYVALE CA 94086 

(408) 738-4800 (DACONICS) 

(415) 494-4464 (XEROX/PARC) 



BRIAN MCGUIRE 
P.O. BOX 1371 
FREMONT CA 94538 



G. CARRICK 

MS970 

FOUR-PHASE SYSTEMS INC. 

19333 VALLCO PARKWAY 

CUPERTINO CA 95014 

(408) 255-0900 X281 



CD 






FAY CHONG 

10405 DEMPSTER AVENUE 
CUPERTINO CA 95014 
(408) 987-1655 



ROD STEEL 
MS 60-456 
TEKTRONIX INC. 
P.O. BOX 500 
BEAVERTON OR 97077 
(503) 638-3411 X2523 



ERIC SCHNELLMAN 
HONEYWELL MARINE SYSTEMS 
5303 SHILSHOLE NW 
SEATTLE WA 98117 



ATTN: PROGRAM LIBRARIAN 

COMPUTING CENTRE 

UNIVERSITY OF ADELAIDE 

BOX 498 G.P.O. 

ADELAIDE S.A. 5001 

AUSTRALIA 

61 822 34333 X2720/X2099 



CO 
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R. GREINER 

MS970 

FOUR-PHASE SYSTEMS INC. 

19333 VALLCO PARKWAY 

CUPERTINO CA 95014 

(408) 255-0900 X231 



BOB PHILLIPS 
2009 N.E. BRAZEE 
PORTLAND OR 97212 
(503) 284-8369 



ATTN: BOEING COMPANY 

87-67 KENT TECHNICAL LIBRARY 

P.O. BOX 3999 

SEATTLE WA 98124 



CD. MARL IN 

DEPT OF COMPUTING SCIENCE 

UNIVERSITY OF ADELAIDE 

ADELAIDE S.A. 5001 

AUSTRALIA 

223 4333 



P. LIAO 

MS970 

FOUR-PHASE SYSTEMS INC. 

19333 VALLCO PARKWAY 

CUPERTINO CA 95014 

(408) 255-0900 X302 



BARRY SMITH 
OMSI COMPUTING 
4015 SW CANYON ROAD 
PORTLAND OR 97221 
(503) 248-5923 



HELLMUT GOLDE 

DEPT . OF COMP .SCI. 

FR-35 

U OF WASHINGTON 

SEATTLE WA 98195 

(206) 543-9264 



B. KIDMAN 

DEPT OF COMPUTER SCIENCE 

UNIVERSITY OF ADELAIDE 

ADELAIDE S.A. 5066 

AUSTRALIA 

23 4333 



en 



RONALD L DANIELSON 
DEPARTMENT OF EECS 
UNIVERSITY OF SANTA CLARA 
SANTA CLARA CA 95051 
(408) 984-4181 



DAVID ROWLAND 

ELECTRO SCIENTIFIC INDUSTRIES 
13900 N.W. SCIENCE PARK DRIVE 
PORTLAND OR 97229 



A. J. GERBER 

BASSER DEPT. OF COMPUTER SCIENCE 

UNIVERSITY OF SYDNEY 

SYDNEY N.S.W. 2006 

AUSTRALIA 



ATTN: SECRETARY 

DEPARTMENT OF INFORMATION SCIENCE 

UNIVERSITY OF TASMANIA 

GPO BOX 252C 

HOBART TASMANIA 7001 

AUSTRALIA 



DADO BANATAO 
3060 BILBO DRIVE 
SAN JOSE CA 95121 
(408) 227-9027 



GARY LOWELL 
2625 HIDDEN VALLEY 
SANTA ROSA CA 95404 
(707) 544-6373 



ATTN: COMPUTER CENTER 
OREGON STATE U 
CORVALLIS OR 97331 



ATTN: DOCUMENTS ROOM 
COMPUTER SCIENCE DEPARTMENT 
U OF OREGON 
EUGENE OR 97403 
(503) 686-4394 



CARROLL MORGAN 

BASSER DEPT. OF COMPUTER SCIENCE 

U OF SYDNEY 

SYDNEY N.S.W. 2006 

AUSTRALIA 



BRIAN G. ROWSWELL 

UNIVERSITY COMPUTER CENTRE 

UNIVERSITY OF SYDNEY 

SYDNEY N.S.W. 2006 

AUSTRALIA 

692 3491 



A. H. J. SALE 

DEPT. OF INFORMATION SCIENCE 

UNIVERSITY OF TASMANIA 

BOX 25 2C 

HOBART TASMANIA 7001 

AUSTRALIA 

23 0561 

0. BEAUFAYS 

MATHEMATIQUES APPLIQUEES 

UN I VERS I TE LIBRE DE BRUXELLES 

AVENUE F.-D. ROOSEVELT 50 

BRUXELLES 1050 

3ELGIUM 
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W. W. PETERSON 
DEPT OF ICS 
U OF HAWAI I 
2565 THE MALL 
HONOLULU HI 96822* 
(808) 948-7420 



ROY CARLSON 
(50-454) 
TEKTRONIX 
P.O. BOX 500 
BEAVERTON 



LESLIE R. KERR 

DAVID L. JOHNSON AND ASSOCIATES 
10545 WOODHAVEN LANE 
BELLEVUE WA 98004 



JOHN D. WOOLLEY 
6722 128TH AVE. SE 
BELLEVUE WA 98006 
(206) 641-3443 



OR 97077 



KEN ROBINSON < ' 
INC. DEPT. OF COMPUTER SCIENCE 

UNIVERSITY OF NEW SOUTH WALES 

P.O. BOX 1 

KENSINGTON N.S.W. 2033 

AUSTRALIA 

663 0351 

ANTHONY P. KYNE 

DEPT. OF COMPUTER SCIENCE 

UNIVERSITY OF MELBOURNE 

PARKVILLE VICTORIA 3052 

AUSTRALIA 

345 1844 



ALAIN PIROTTE 

MBLE/RESEARCH LABORATORY 

AVENUE EM. VAN BECELAERE 2 

BRUSSELS B-1170 

BELGIUM 

673.41.90 

673.41.99 

SERGIO DE MELLO SCHNEIDER 

DEPARTAMENTO DE COMPUTACAO 

UN I VERS I DADE FEDERAL DE SAO CARLOS 

SAO CARLOS SP 13560 

BRAZIL 
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F. CELLINI 

DEPT. OF COMPUTER SCIENCE 

UNIVERSITY OF WESTERN ONTARIO 

LONDON ONTARIO 

CANADA 

(519) 679-6051 



FRANKLIN B. DE GRAAF 

6 CARMICHAEL COURT 

KANATA ONTARIO K2K 1 K2 

CANADA 



W. MORVEN GENTLEMAN 

MATHEMATICS COMPUTING FACILITY 

UNIVERSITY OF WATERLOO 

WATERLOO ONTARIO N2L 3G1 

CANADA 

(519) 885-1211 



ATTN: LIBRARY 

PERIODICALS SECTION 

UNIVERSITY OF ALBERTA 

EDMONTON ALBERTA T6G 2J8 

CANADA 



-o 
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ATTN: M. DOHERTY 

128 TECHNICAL REFERENCE CENTER 

UNIVERSITY OF TORONTO COMPUTER CENTER 

10 KINGS COLLEGE ROAD 

TORONTO ONTARIO 

CANADA 

(416) 978-8995 

F. G. PAGAN 

COMPUTER SCIENCE 

MEMORIAL UNIVERSITY 

ST. JOHN'S NEWFOUNDLA A1C 5S7 

CANADA 



ATTN: REFERENCE ROOM 
COMPUTING AND INF. SCI . 
QUEEN'S UNIVERSITY 
KINGSTON ONTARIO K7L 
CANADA 



R. D. TENNENT 

DEPT. OF COMPUTING. AND 

QUEENS UNIVERSITY 

KINGSTON ONTARIO 

CANADA 



3N6 



INFORMATION SCI 



K7L 3N6 



ATTN: PROGRAM LIBRARY 

COMPUTING CENTER 

223 NATURAL SCIENCE CENTER 

U OF WESTERN ONTARIO 

LONDON ONTARIO N6A 5B7 

CANADA 

(519) 679-2151 



L. C. PORTIL 

COMPUTER CENTRE 

U OF WINDSOR 

WINDSOR ONTARIO 

CANADA 

(519) 253-4232 X645 



N9B 3P4 



BARY W. POLLACK 

DEPT . OF COMP .SCI. 

U OF BRITISH COLUMBIA 

2075 WESBROOK PLACE 

VANCOUVER BC V6T 1W5 

CANADA 

(604) 228-6794 



DOUG DYMENT 

6442 IMPERIAL AVE. 

W. VANCOUVER B.C. 

CANADA 

(604) 921-7954 



V7W 2J6 






J. W. ATWOOD 

DEPT OF COMP. SCI.:H963-10 

CONCORDIA UNIVERSITY 

1455 DE MAISONNEUVE BLVD. WEST 

MONTREAL QUEBEC H3G 1M8 

CANADA 

(514) 879-8130 

D. B. COLDRICK 

COMPUTATION CENTRE 

BLDG. M-60 

NATIONAL RESEARCH COUNCIL 

MONTREAL ROAD 

OTTAWA ONTARIO K1A 0R6 

CANADA 

LUIGI' LOGRIPPO 

COMP. SCI. DEPT. 

U OF OTTAWA 

OTTAWA ONTARIO K1N 6N5 

CANADA 



H. TAYLOR 

COMPUTING CENTRE 

APPLICATIONS DEPT. 

U OF OTTAWA 

OTTAWA ONTARIO K1N 6N5 

CANADA 



ATTENTION: DONALD LINDSAY 

DYNALOGIC CORPORATION LIMITED 

141 BENTLEY AVENUE 

OTTAWA ONTARIO K2E 6T7 

CANADA 

(613) 226-1383 



N. SOLNTSEFF 

DEPT. OF APPLIED MATH. 

MCMASTER UNIVERSITY 

HAMILTON ONTARIO L8S 4K1 

CANADA 

(416) 525-9140 X4689 



MIKE KIMBER 

DATA CENTRE 

THE GLOBE AND MAIL 

444 FRONT ST. WEST 

TORONTO ONTARIO 

CANADA 



HENRY SPENCER 

SP SYSTEMS 

BOX 5255 STATION A 

TORONTO ONTAR 1 

CANADA 



M5V 2S9 



M5W 1N5 



ANNE STOCCO 

COMP. AND INFO. SCIENCE 

108 I.C.S. 

UNIVERSITY OF GUELPH 

GEULPH ONTARIO N1G 2W1 

CANADA 

X2259 



CHARLES H. FORSYTH 

APT. 2-304 

300 REGINA ST. N. 

WATERLOO ONTARIO 

CANADA 

(519) 884-7531 



N2J 4T2 



G. D. DERHAK 
COMPUTER CENTRE 
U OF MANITOBA 
WINNIPEG MANITOBA 
CANADA 



R3T 2N2 



W. BRUCE FOULKES 

DEPARTMENT OF COMPUTER SCIENCE 

THE UNIVERSITY OF MANITOBA 

WINNIPEG MANITOBA R3T 2N2 

CANADA 

(204) 474-8466 



STEPHEN SOULE 

DEPT. OF COMP. SCI. 

U OF CALGARY 

CALGARY ALBERTA T2N 1N4 

CANADA 

(403) 284-6780 



BRIAN W. UNGER 

COMPUTER SCIENCE DEPT. 

UNIVERSITY OF CALGARY 

CALGARY ALBERTA T2N 1N4 

CANADA 

(403) 284-6316 



B. VENKATESAN 

DEPT. OF COMPUTER SERVICES 

U OF CALGARY 

2920 24TH AVE. N.W. 

CALGARY ALBERTA T2N 1N4 

CANADA 

(403) 284-6207 



ATTN: DATALOGISK INST I TUT 
COPENHAGEN UNIVERSITY 
SIGURDSGADE 41 
COPENHAGEN N DK-2200 
DENMARK 



LARS CHRISTENSEN 

ALDERSHVILEVEJ 16 

BAGSVAERD DK-2880 

DENMARK 

009 45 2 98 20 09 



PREBEN TAASTi 
COMPUTER CENTER 
UNIVERSITY OF AALBORG 
STRANDVEJEN 19 
AALBORG DK-9000 
DENMARK 
(08) 138 788 

L. BRANDT 

DET REGIONALE EDB-CENTER 

AARHUS UNIVERSITET 

AARHUS C. 8000 

DENMARK 

06 - 12 83 55 
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ANTTI SALAVA 


ro 


DEPT. OF COMPUTER SCIENCE 


cr> 


UNIVERSITY OF HELSINKI 


rn 


TOOLONKATU 11 




HELSINKI 10 SF-00100 


ro 


FINLAND 


U1 



JUHA HEINANEN 

DEPARTMENT OF COMPUTER SCIENCE 

UNIVERSITY OF TAMPERE 

BOX 607 

TAMPERE 10 SF-33101 

FINLAND 



LUC I EN FEIEREiSEN 
EDELSHEIMSTR. 4 
KARLSRUHE 1 D-7500 
GERMANY . 



ATTENTION: N. V. KOTESWARA RAO 

COMPUTER TRG. UNIT 

ELECTRONICS CORPORATION OF INDIA 

HYDERABAD (AP) 500762 

INDIA 

71611 



TERUO HIKITA 

DEPT.' OF INFO. SCI . 

U OF TOKYO 

TOKYO 113 

JAPAN 

03-812-2111 X2947 



GO 

<-> 



0. LECARME 

I .M.A.N. 

UN I VERS I TE DE NICE 

PARC VALROSE 

NICE CEDEX 

FRANCE 



06034 



P. MAURICE 

INFORMATIQUE 

UN I VERS I TE PAUL SABATIER 

118 ROUTE DE NARBONNE 

TOULOUSE CEDEX 31077 

FRANCE 



GERHARD GOOS 

INST I TUT FUER INFORMATIK I I 

UN I VERS I TAT KARLSRUHE 

POSTFACH 6380 

KARLSRUHE 1 D-7500 . 

GERMANY 

0721/608-3970 

ATTENTION: JAN WITT 

ZFE FL SAR 

SIEMENS AG 

HOFMANNSTR. 51 

MUNCHEN 70 D-8000 

GERMANY 

(089) 722-22651 



MICHAEL Z. HAN AN I 

COMPUTATION CENTER 

BEN GURIAN UNIVERSITY OF THE NEGEV 

BEER-SHEVA 

ISRAEL 



RUTH WEINBERG 

COMPUTATION CENTER 

HEBREW UNIVERSITY OF JERUSALEM 

JERUSALEM 

ISRAEL 

02-32011/280 



E I I TA WADA aC 

DEPARTMENT OF MATHEMATICAL ENGINEERING to 
UNIVERSITY OF TOKYO |— 

BUNKYOKU TOKYO 113 m 

JAPAN -H 

(03) 812-2111 X7486 -H 



TOSH I AK I SAISHO 
1-25-7 KITAMAGOME 
OOTA-KU TOKYO 
JAPAN 



m 

7a 



143 



JEAN-PIERRE FAUCHE 
DEPARTMENT INFORMATIQUE 
I REP 
BOITE POSTALE 47 



GRENOBLE 
FRANCE 



CEDEX 



38040 



ALBRECHT BIEDL GIDEON YUVAL 

INST I TUT FUR SOFTWARETECHNIK UND THEOR COMPUTER SCIENCE 

DV-GRUNDAUSBILDUNG THE HEBREW UNIVERSITY 

TECHNISCHE UNIVERSITAT BERLIN JERUSALEM 

OTTO-SUHR-ALLEE 18/20 ISRAEL 

1000 BERLIN 10 VSH 419 

GERMANY 



MASARU WATANABE 
9-16 SHINOHARADAI 
KOHOKU-KU YOKOHAMA 
JAPAN 



222 



ALAIN TISSERANT 

DEPARTEMENT I NFORMAT I QUE 

ECOLE DES MINES 

PARC DE SAURUPT 

NANCY CEDEX 54042 

FRANCE 



GERHARD FRIESLAND 
INST I TUT FUR INFORMATIK 
UNIVERSITAT HAMBURG 
SCHLUETERSTRASSE 70 
HAMBURG 13 2 
GERMANY 



HORST SANTO 

GESELLSCHAFT FUER MATHEMATIK UND DATEN 

INST I TUT FUER PLANUNGS UND ENTSCHEIDUN 

POSTFACH 1240 SCHLOSS BIRLINGHOVEN 

ST. AUGUST IN 1 D-5202 

GERMANY 



H.-J. HOFFMANN 
FACHBEREICH INFORMATIK 
TECHNISCHE HOCHSHULE 
STEUBENPLATZ 12 
DARMSTADT D-6100 . 
GERMANY 



ASHOK N. ULLAL 
KARLSTR. 1 

JETTENBURG D-7401 
GERMANY 



IRVING N. RABINOWITZ MAKOTO ARISAWA - 

DEPT. OF COMP. SCI. COMPUTER SCIENCE DEPARTMENT 

TECHN ION- ISRAEL INSTITUTE OF TECHNOLOG YAMANASHI UNIVERSITY 

TECHNION CITY HAIFA 4-3-11 TAKEDA KOFU 
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UNITED KINGDOM 


NEWTON J. MUNSON 


13676 




CHARLES E. MURPHY 




LIBYA 


HARRY M. MURPHY JR. 


87117 




H.-H. NAGEL 


2 


GERMANY 


T. A. NARTKER 


87801 




JOHN NAUMAN 


55455 




MARK S. NIEMCZYK 


60015 




R. K. NORDIN 


55454 




THEODORE A. NORMAN 


84602 




DAVID A. NUESSE 


54701 




JOHN NUNNALLY 


72143 




CAROL A. OGDIN 


22314 




RICHARD OHRAN 


84602 




RON OLSEN 


07733 




LENNART OSKARSSON 


S-431 20 


SWEDEN 


MARK OVERGAARD 


92093 




DANIEL M. O'BRIEN 


61820 




MAURICE 0' FLAHERTY 


ANTRIM UNITED KINGDOM 


F. G. PAGAN 


A1C 5S7 


CANADA 


PETER PAWELCZAK 


10019 





PATRICK PECORARO 


85721 




SHMUEL PELEG 


20742 




WALT PERKO 


55414 




DAVID PERLMAN 


55455 




W. W. PETERSON 


96822 




CHARLES PFLEEGER 


37916 




BOB PHILLIPS 


97212 




ALAIN PIROTTE 


B-1170 


BELGIUM 


STEPHEN A. PITTS 


73110 




RUDOLPH C. POLENZ 


54701 




BARY W. POLLACK 


V6T 1W5 


CANADA 


GEORGE POONEN 


02168 




L. C. PORTIL 


N9B 3P4 


CANADA 


J. L. POSDAMER 


13210 




FRED W. POWELL 


24401 




RON PRICE 


07726 




WILLIAM C. PRICE 


91107 




ANDREW S. PUCHRIK 


22090 




BRUCE A. PUMPLIN 


54701 




HOWARD D. PYRON 


65401 




DOUGLAS H. QUEBBEMAN 


47130 




IRVING N. RABINOWITZ 




ISRAEL 


V. LALITA RAO 


18015 




WAYNE RASBAND 


20014 




JEFFERY M. RAZAFSKY 


64108 




ROY F. REEVES 


43220 




PHYLLIS A. RE ILLY 


90746 




ROBERT REINHARDT 


61 000 


YUGOSLAVIA 


JOHN REYNOLDS 


N8 


UNITED KINGDOM 


GEORGE H. RICHMOND 


80309 




PETER A. RIGSBEE 


20375 




MARK RIORDAN 


48824 




CLARK M. ROBERTS 


91016 




JOE C. ROBERTS 


21851 




KEN ROBINSON 


2033 


AUSTRALIA 


STAFFEN ROMBERGER 


S-100 44 


SWEDEN 


BERN IE ROSMAN 


01701 




E. L. ROWE 


19301 




DAVID ROWLAND 


97229 




BRIAN G. ROWS WELL 


2005 


AUSTRALIA 


HERBERT RU3ENSTEIN 


55455 




NANCY RUiZ 


87115 




MARK RUSTAD 


55112 




FRANK RY3iCKI 


19122 




JONATHAN SACHS 


60604 




TOSHIAKI SAISHO 


143 


JAPAN 


ANTTI SALAVA 


SF-00100 


FINLAND 


A. H. J. SALE 


7001 


AUSTRALIA 


TIMOTHY J SALO 


55455 




CHESTER J. SALWACH 


18960 




TOM SANDERSON 


87002 




HORST SANTO 


D-5202 


GERMANY 


DAVID SARANEN 


55792 




AARON SAWYER 


02035 




BOB SCARLETT 


55455 




G. MICHAEL SCHNEIDER 


55455 




SERGIO DE MELLO SCHNEIDER 


13560 


BRAZIL 


' ERIC SCHNELLMAN 


98117 




STEPHEN C. SCHWARM 


19898 




FRED L. SCOTT 


33314 
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WAYNE SEIPEL 


78712 




GUISEPPE SELVE 


40122 


ITALY 


SHARAO C. SETH 


68588 




ED SHARP 


84112 




DAVID ELLIOT SHAW 


94022 




WILLIAM F. SHAW 


01754 




BEN SHNEIDERMAN 


20742 




JAMES P. SHORES 


06320 




LEO J. SLECHTA 


55165 




BARRY SMITH 


97221 




BROOKS DAVID SMITH 


53211 




. ROBERT J . SNYDER 


46202 




THOMAS C. SOCOLOFSKY 


43823 




MARY LOU SOFFA 


15260 




N. SOLNTSEFF 


L8S4K1 


CANADA 


DAVID SOLOMONT 


02155 




MARCO SOMMANI 


1-56100 


ITALY 


NORMAN E. SONDAK 


01609 




STEPHEN SOULE 


T2N 1N4 


CANADA 


HENRY SPENCER 


M5W 1N5 


CANADA 


RICHARD D. SPILLANE 


07470 




ROD STEEL 


97077 




EDWARD STEEN 


01852 




GORDON A. STEGINK 


49401 




HAL STEIN 


47401 




ALBERT STE1NER 


60201 




ANNE STOCCO 


NIG 2W1 


CANADA 


A. 1. STOCKS 


70504 




JOHN P. STRAIT 


55455 




GEORGE 0. STRAWN 


50011 




ROBERT A. STRYK 


55424 




PREBEN TAASTI 


DK-9000 


DENMARK 


RAMON TAN 


18016 




ANDREW S. TANENBAUM 




THE NETHERLANDS 


DAVID TARABAR 


01701 




H. TAYLOR 


KIN 6N5 


CANADA 


JANET TAYLOR 


75275 




RICHARD TAYLOR 


80212 




WILLIAM P. TAYLOR 


94550 




MICHAEL TEENER 


90403 




R. D. TENNENT 


K7L 3N6 


CANADA 


TED TENNY 


13676 




GAY THOMAS 


39762 




RON THOMAS 


55425 




JACK THOMPSON 


62025 




LARS-ERIK THORELLI 


S-100 44 


SWEDEN 


LAVHSIE THRAILKILL 


40506 




ALAIN TISSERANT 


54042 


FRANCE 


STEPHEN TITCOMB 


18017 




NOBUKi TOKURA 


500 


JAPAN 


HOWARD E. TOMPKINS 


15701 




ALFRED 1 . TOWELL 


47401 




ASHOK N. ULLAL 


D-7401 


GERMANY 


BRIAN W. UNGER 


T2N 1N4 


CANADA 


JOHN URBAN SKI 


55403 




INDULIS VALTERS 


55406 




J. J. VAN AMSTEL 




THE NETHERLANDS 


ANDRIES VAN DAM 


02912 




PATRICIA VAN DERZEE 


45036 




H. VAN LOON 




THE NETHERLANDS 



T. J. VAN WEERT 


8131 


THE NETHERLANDS 


WILLIAM J. VASILIOU JR. 


03324 




ROBERT D. VAVRA 


55113 




B. VENKATESAN 


T2N 1N4 


CANADA 


E I 1 TA WADA 


113 


JAPAN 


WILLIAM M. WAITE 


80302 




TERRY M. WALKER 


70504 




RANDALL W. WARREN 


55440 




SCOTT K. WARREN 


77098 




MASARU WATANABE 


222 


JAPAN 


GEOFF WATTLES 


55414 




JOHN A. WEAVER 


18018 




NEIL W. WEBRE 


93401 




WALLY WEDEL 


78712 




W. WEHINGER 


7000 


GERMANY 


RUTH WEINBERG 




I SRAEL 


LEONARD H. WEINER 


79409 




STEVE M. WEINGART 


55113 




JOHN WERTH 


89154 




JOHN P. WEST 


30332 




TERRY E. WEYMOUTH 


68510 




GEORGE H. WILLIAMS 


12308 




JOHN H. WILLIAMS 


14850 




GARY W. Wl NIGER 


94088 




GREGORY J. WINTERH ALTER 


30092 




Nl KLAUS WIRTH 


94304 




DAVID S. WISE 


47401 




BILL WOOD 


55455 




JOHN D. WOOLLEY 


98006 




JACOB C. Y. WU 


20910 




STEPHEN W. YOUNG 


47401 




L. W. YOUNGREN 


55901 




GIDEON YUVAL 




ISRAEL 


RUSSELL W ZEARS 


77550 




PETER H. ZECHMEISTER 


55117 




E. C. ZIMMERMAN 


44691 
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by S. Knudsen, Institut fur Inform,-! t ik 

F. T. M. , Zurich 
translated by J. H. Eoesch, SSRFC 

University of Minnesota 

Tn addition to the possibility of dividing sequential files into 
segments (creating a "segmented file"), it is aiso possible to 
construct, read, and modify indexed files. This feature also covers 
the need for rapid location and modification of segments. 

An indexed f i Le may be thought of as a sequential file divided into 
segments (that is, as a segmented file). Each segment describes a 
possibly empty series of component- type elements and is a "logical 
record" in COO SCOFF terminology. i n contrast to segmented files in 
which a segment can be located through tlie use of a segment number 
relative to the previous segment, a segment of an indexed file can be 
found through the use of a specific segment reference address (a 
so-called random index), which is returned from the system during the 
write operation. 

Declaration: 

<f lie type> : := indexed file of <type> 

Example: 

type ift = indexed file of t 

The component type <type> cannot be char: Indexed textfiies are not 

implemented « 

The standard functions F,OF and EOS are defined as for segmented files 
and are likewise valid with indexed files. The standard procedures 
PUT, GRT, and RESET (hence READ and URITE) are defined as for 
segmented files. The procedures REWRITE, PUTSEO, and GET SEP., however, 
are defined for indexed files as follows: 

RESET(f) positions f at the beginning. This allows the first of the 
segments described by the file to be read. 

RE'.JRITE(f) initializes the writing of a new segment at the end of the 
file f. The new segment is thereforo not written at the 
beginning. 

PUTSFO(f,k) must be called when a new segment is to be closed. The 
segment index (of type 1..2T24-1) corresponding to the segment 
location is returned in k. 

RE\IRITE(f ,k) initializes for rewriting the segment with index k. k 
must be an index that was returned from. PUTSEO. 

PUTSEO(f) must be called to close a rewrite operation. 

N'R . If a segment that is longer than the original segment is 
rewritten, segments following it may be overwritten. 



GETSEG(f) is called to initialize the reading of the next segment. An 
indexed file can therefore be read as a sequential file. 

GETSEG(f,k) initinlizes the reading of a segment with the index k. k 
must be an index that was returned from a call to PUTSEO. 

Some program examples will clarify the way in which indexed files are 
used. The basic declarations are: 

var index: array [1 .. n] of t; 
i, k: integer; p: boolean; 

Write an indexed file f with n segments; the reference address 
of each segment is maintained in an arrav of indices. 

rewrite(f ) ; 
for i := 1 to n do 
begin 

while p do 

begin (* fill ft *); put(f) end : 
putseg(f, index [i]) 
end 

Append a new segment. Its index is returned in k. 

rewrite(f ) ; 
while p do 

begin (* fill ft *) ; put(f) end ; 
putseg(f ,k) 

Sequentially read an indexed file. 

reset (f ) ; 

while not cof(f) do 
begin 

while not eos(f) do 

begin (* inspect ft *); get(f) end ; 
getseg(f) 
end 

Read a segment with index k. 

getseg(f ,k) ; 

while not eos(f) do 

hegin (* inspect ft *) ; get(f) end ; 

Rewrite a segment with index k. 

rewrite(f , k) ; 
while p do 

begin (* fill ft *); put(f) end ; 
putseg (f ) 
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The Need for Hierarchy and Structure 
in Language Management 

by 

G. Michael Schneider 

Department of Computer Science 

University of Minnesota 

I find it quite ironic that so much concern is being paid problems of 
structure and organization of statements wi thin the PASCAL language but so 
little to the structure and organization of the management of the language 
itself. By this I mean that there is currently lacking a formal administrative 
hierarchy for the handling of questions relating to language standards, 
specifications, and extensions. 

When PASCAL usage was small and consisted of only a few installations, 
language management could easily be handled by doing whatever you wanted to or 
by verbal agreements among all parties concerned. Disagreements could be 
settled by simple exchange . of letters, telephone calls or over coffee. 

The usage of PASCAL has, I believe>now left this embryonic stage of development. 
Merely witness the nearly 500 members of nhe PASCAL Users Group or the dozens 
of Universities now using it as their primary language. 

Yet while the growth of the language has been phenomenal the administration 
of the language has not. It has remained a loose knit, informal mechanism 
composed of the creators, users, and maintainers of the language. This is a 
chaotic way to administer any large system and, worst of all, leaves the 
language open to chaotic, unstructured growth. It is also frustrating. To 
whom do we submit suggestions on changes, deletions, improvements, or extensions 
to the language? To whom do we submit our "beautifully lucid" arguments on 
what needs to be done? Currently there is no one. This groundswell of frustra- 
tion was clearly demonstrated by the dozens of letters received by the Newsletter 
shortly after it began, which described suggested improvements or changes. A 
few of the suggestions I felt were good, most quite bad. That, however, is not 
the important point. What is important Is that these letter writers had been 
searching for a vehicle to formally submit proposals and immediately leaped at 
the Users Group and its publication as just that vehicle. But, the Users 
Group has absolutely no official status as the arbiter of language standards. 
The needed administration is still lacking. 



What i propose ?s that we (the User's Group members) begin to discuss what is 
needed for the proper administration of PASCAL. I initially suggest that 
we adopt the following proposal: 

The PASCAL User's Group nominate and vote on a PASCAL 
Standards Committee composed of about 10-15 members. 
This committee must initially perform three functions: 

1) Attempt to seek formal recognition for itself 
with such groups as SIGPLAN, ACM, and ANSI. 

2) Certify an official PASCAL standard. While this 
will probably be the specifications found in 

the PASCAL report, it should clear up certain 
"grey areas" (e.g., dispose). 

3) Draw up a "constitution" which spells out the role 
of the committee, its term in office, the 
philosophy to be used in evaluating proposed 
standards, and a formal procedure for submitting 
proposals to the committee. 

The committee should now accept and consider suggestions 
from throughout the user community. It should solicit 
opinions and arguments on the proposal, evaluate all 
suggestions in light of the stated philosophy 
of the PASCAL language and decide to reject it, accept it 
as a new standard, accept it as a standard extension, or 
postpone any decision. Major decisions could be put to 
a vote of the full membership if necessary. 

The above proposal omits a great amount of detail that can be worked out by 
the committee and the membership. It would be presumptious of me two impose 
any further my own feelings on how such a standards committee should operate. 

What I care about are not really the details anyway. I care about bringing 
order and structure to the area of language management -- the same goals that 
PASCAL brought to language design. 

(*Received 10/1/76*) 
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On the suitability of a Pascal Compiler in an 
undergraduate teaching environment 

Before Pascal was adopted by my parent department for teaching purposes, 
it was necessary to demonstrate that a suitable compiler was available. 
We have access to a CYBER 72 running a timesharing service under NOS and 
consequently acquired from Zurich the 6000 -3.4 compiler. The performance 
of the compiler during installation gave rise to a great deal of optimism and 
a few reservations. The optimism stemmed from the quality of the compiler; 
the reservations from a few obvious problems caused by the change from 
SCOPE 3.4 to NOS. These problems were almost entirely caused by the change 
in the method of use of the compiler not by defects on the code. 

The local modifications were all introduced with one purpose in mind - 
to facilitate the use of Pascal for undergraduate teachincj. 

The modifications can be roughly divided into two categories. 

1 . Modifications to ease the use of Pascal 

a) the compiler ignores leading line numbers 

b) compilation diagnostics are sensible with the L-option 

c) post-mortem dump output is re-formatted for 70 character wide devices. 

d) day file messages were re-ordered so that the fault reason appears on 
the terminal. 

e) terminal control introduced - a user interrupt will produce a post-mortem 
dump. 

f) the post-mortem dump gives traceback information in terms of line 
numbers not core addresses 

2. Modifications to improve throughput 

a) A G+ option to automatically enter a correctly compiled program 

b) A W option, which allows the use of blank common for stack + heap. 
This reduces the possibility of rollouts which may be caused if a 
memory request for an increase in field length were made. 

Note 

To minimise store requirements we wish to run Pascal in REDUCE mode, 
and under NOS the KRONOS 'trick' to avoid field length reduction 
after a relocatable load does not work . 

c) Output buffers which are on-line to a terminal are not flushed by the 
Pascal run-time system at the end of a run. This is left to the time- 
sharing system. This change was made as the result of a poor benchmark 
performance. 

To demonstrate that the performance of the compiler was satisfactory 
a simple benchmark was designed to compare Pascal with Algol 60 and 



Fortran. It was believed that this benchmark would saturate our 
system. 

The benchmark consisted of running 7. r > jobs as rapidly as possible from 
15 terminals (5 from each terminal) with no other users on the machine. The 
experiment was repeated 4 times for each language;; f*ach t ime with a different 
job. The amount of real time elapsed was measured in each case. These figures 
include the time for terminal I/O which was expected to be small by comparison 
with the total time. 

For the experiment we used: 

a Zurich Pascal compiler with local mods (but not 2c above) 
an FTNTS compiler 

an ALGOL 4 compiler via a procedure file which included utilities 
for handling the line number problem, 
and 15 'volunteers', many of whom had never used the system before. 
Jobs 1 and 2 involved similar programs. In Job 1 the program was 
altered to introduce a compilation fault. Job 2 compiles OK and is executed. 
Jobs 3 and 4 are related in a similar way. The programs used were genuine 
student exercises. The 'same' program was used for each language. 
Results 



Job 
Number 



Time in seconds for 
Algol Fortran Pascal 



701 


245 


426 


1956 


<J 58 


190 


846 


254 


* 


2967 


440 


220 



*The Pascal experiment was terminated as the performance was 

unsatisfactory. 
Modification 2c was included and experiment repeated. The results 
were 153, 155, 1^1 and 201 seconds respectively. 

These figures are interesting for two reasons 

1. the improvement from -i26 to 153 for Job 1 

2. the fact that Job 3 took less time that Job 1 

Fact 1 can be explained by the introduction of the extra modification which 
reduced the core <-> disc traffic by 

75 x 4 x 50000B words per benchmark 
= 61.4 million characters 
for the benchmark involving compilation errors. 
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Fact 2 can be attributed to the human learning process. As the 
experiment progressed the volunteers were able to type the commands faster 
because they were more familiar with the system. 

In fact the performance of the Pascal compiler is such that the figures 
presented for the second experiment can only be regarded as a lower bound 
on the throughput because the terminal I/O now accounts for a significant 
proportion of the time measured, e.g. 

in a faulty compilation benchmark:- 

no. ot characters typed by human at a terminal = 65 
" " " " " system at a terminal = 540 

assuming typing speeds of 3 and 10 chars/sec. this accounts for 76 seconds 
at every terminal. It seems likely that the system is not being saturated 
by this benchmark when using Pascal. 

Conclusions 

1, The performance of Pascal is satisfactory 

2. These figures represent a lower bound on its performance. More 
accurate figures would have required the use of a greater number of 
terminals (to saturate the system) and repetition of the experiments. 
In the context of the experiments this would have been a waste of time. 



A. M. Addyman 



(*Received 10/4/76*) 



PASCAL Potpourri 
by Richard J. Cichelli 

Topics for the PASCAL user: 
Direct access files 
"Standard" PASCAL 
Software tools 

Direct Access Files for PASCAL 

The following is presented as an approach to direct access 
files in PASCAL. We begin with a discussion of current PASCAL 
file facilities. 
S equential Files in PASCAL 

The PASCAL Revised Report defines only sequential files for 
PASCAL. Thus, a file is a sequence of zero or more items of the 
same type, A window, or buffer variable , into the sequence is 
defined. It is referenced by a buffer pointer . Only one element 
of a file may be accessed at any time. A predicate EOF (end of 
file) Ls defined such that when it is true, the operation 
WRITE ( <file item> ) or PUT ( ^buffer variable> ) is valid. If EOF 
is false,. READ (<file item> ) or GET ( <buffer variable> ) is 
possible. As a side effect of the READ and WRITE operations, the 
buffer pointer is moved through the sequence. EOF becomes true 
during a sequence cf REABs when no items remain beyond the buffer 
pointer. EOF remains true after a WRITE. The operations RESET and 
REWRITE move the buffer pointer to the beginning of the sequence. 

PASCAL sequential files look like tapes. 
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The Notions of Direct Access Flies 

Most mass storage based operating systems present files to 
the user as named data sets (i.e. groups of related items 
associated under a cataloged name in a directory). The user can 
request access to a data set by supplying the system with its 
name. PASCAL sequential files are easily provided in most 
operating systems. However, the vast majority of third generation 
operating systems give the user an alternative to the tape- like 
file organization capabilities of PASCAL files. This alternative 
allows data items to be accessed directly . That is, if the "file" 
consists of 1000 items, the user can access the 439th without 
passing the 433th or rewinding from the 440th. 

For direct access files there is -no notion of a buffer 
pointer, and thus there is no EOF, RESET, or REWRITE. Any item 
may be read or modified "in place". READs and WRITES can occur 
in any order. 

The nearest notion to this idea that is defined in the PASCAL 
Report is that of arrays . I propose to extend the PASCAL array 
concept to provide direct access facilities. 

To accomodate this extension to the language, I propose that 
the type declaration for arrays be extended from 



-**( ARRAY, 



A "long" array will be one which might reside on direct access 
secondary mass storage. 
Consequences of the Not a tion 

Treating direct access files as arrays requires only relative 
record I/O capabilities from the operating system. It seems to me 
that this provides the potential for all direct access facilities 
at the most fundamental level. It suggests that such advanced 
notions as "indexed sequential access" will have to be implemented 
by the programmer or as utilities in terms of the above primitives. 
Implementation Details 

Direct access files are used in two basically different ways - 
as bulk temporary work space and for fast, non-sequential access 
to permanent data using keys based upon content or relationships. 
To serve the first need, the long array can simpiy be a local 
array variable. In a virtual memory environment the word "long" 
might be ignored by the compiler. As far as the programmer is 
concerned, this type of long array is equivalent to a (possibly) 
a i ov; a c c ess a r ray . 

For the second case, long arrays are global to the program. 
They will be named as formal file parameters in the program 
heading just as global files are now. Their declarations will be 
in the variable declarations of the program, or level 0, block. 

If a long array file doesn't exist when a program declaring 
it is executed, one should be created (and should remain upon 
program termination). If one does exist but is incompatible with 



Andy informs me that someone has already implemented inaexed 
files in PASCAL. From my conversations with him, I do not 
believe I jam duplicating this effort. 



This .13 quite simple. A relative record file (long array) is 
used for the records and another is used for tne related index 
which maps from primary key designator to the record number (i.e. 
long array index). Both arrays might be mapped into the same 
system file by using record variant parts for array elements. 
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the program definition, a fatal error should result. Other fatal 
error conditions will arise if the actual file is sequential or 
if it is the wrong size (i.e. any type mismatch). 

Several programmer notations could be used to guide the compiler 
in mapping the data items into efficient store. For example, tne 
declaration "PACKED LONG ARRAY" might cause the compiler to try to 
block the records efficiently. By extending the dollar sign 
comment notation, the programmer might suggest blocking factors 
and the number of core resident direct access record areas. 
User Interface 

Long arrays will be used exactly like in core arrays. Of 
course, a long array of files or a long array of long arrays 
can "not be premitted. Other than this obvious restriction, a 
long array will be like any other array. Access notation will 
be identical. 

There is one glaring disadvantage with this scheme, however. 
When- a programmer writes expressions using long array elements, 
he may invoke significant overhead ... and it will be almost 
completely invisible to him in the code text. The phrase 
"long array" just doesn't suggest long moments of computer toil 
to the programmer. The best sort for a long array may in no way 
resemble the best for an in-core array. 

* I suspect, however, the days of slow access rotating magnetic 
storage are limited. Solid state bulk memory seems destined to 
overtake disks. Our notation may be more appropriate for the 
future than the present. 



Conclusion 

I suggest that the concept of "long arrays" is sufficient 
for direct access file facilities and is consistent with the 
design goals of PASCAL in its simplicity and clarity. 

Standards and the Language PASCAL 
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The standards game is one played by programming language 
users. Those with problems in search of solutions look for new 
language features. Those with programs searching for customers 
with problems look to enforce standards. We PASCALers should 
have a total view of the standards problem. We should realize that 
no existing programming language standard is a success at its 
stated goals and that no language has succeeded without a 
standard. With respect to standards, PASCAL has significant advantages 
over the popular poorer languages. First, it is defined only in 
the Revised Report and not in some vendor's implementation. 
Second, as a language it seems particularly easy to formalize in 
a humanly understandable fashion. In short, it has a small and 
regular syntax. 
Do We Need a Formally Recognized Standard ? 

Let us consider the population concerned with PASCAL and 
PASCAL standardization: language designers, language implementors, 
program writers, and employers of program writers. 

Language Designers 

In our case, this is Dr. Niklaus Wirth. He says PASCAL is 
what he says it is. Eut, in fact, PASCAL is too important and 
too widely used to have its scope defined and limited by one man. 
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We all have a legitimate say in this and we can and should exercise 
our responsibility. It la important, however, to recognize that 
the current success of PASCAL is based on its eloquent design. 
We must seek to preserve iis simplicity and clarity above all else. 

Lang uage Imp lem e n tor s 

Dr. Urs Amman n and his group implemented PASCAL in an efficient 
and robust fashion on the CDC 6000 computers. Because many users 
confuse a programming language with its particular implementations, 
Ammann's fine implementations have been the wellspring of PASCAL 
user growth. Because many imp lemen tors have followed Ammann's lead, 
it Is iikely that the PASCAL compiler is the most efficient 
language processor at any shop which has one. 

Implementors desire standards to guide their compiler writing. 
Frequently however, in order to Interface or compete with existing 
languages, they stretch or reinterpret the standards to meet real 
or imagined user implementation needs. Implementors and compiler 
maintainers should take great care not to let ad hoc patches to an 
implementation become de facto changes to the language standard. 

Fortunately, no hardware vendor has tried to make PASCAL 
its own. But we all know that PASCAL will soon be a veridor product. 
This should not be viewed as auguring potential corruption, but 
instead as a sign of maturation. We should recognize it as such 
and provide vendors with an excellent standard to work from. I 
personally anxiously await the day when Seymour Cray, Gene Amdahl, 
and Ken Olsen market PASCAL machines. 



7. 

Users: Managers and Programmers 

For obvious reasons, organizations and their representatives 
(i.e. managers) want standardization in a programming language. 
Every organization has learned Whitney's lesson about 
interchangeability. In programming this means adherence to 
standards . 

Programmers have problems to solve. There are things which 
could be added to PASCAL that might make one programmer's job 
easier. The problem is to address the entire user community. 
Frankly, some languages are better than PASCAL for some applications: 
use COBOL 1 s Report Writer for reports, use SNOBOL for string 
manipulation, etc. PASCAL can't be all things to all people and 
still be simple, concise and easily implemented. Remember the 
PL/I syndrome - multi -million dollar compilers won ! t solve 
anyone's problems. There is a revolution coming in computer 
software as more programmers learn how to do more things simply . 
Getting a Recognized Standard 

A standards committee should be set up. (I would particularly 
like to see Dr. Waite as a member.) This committee would represent 
users and designers first, implementors and vendors second. Its 
purpose would be to get a document approved by both PUG members 
ana the ANSI-X3J3 committees. International standardization is 
also desirable. Additionally the committee would be charged with 
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It is the naive manager who thinks hardware vendors desire 
standards. As the current efforts with big languages indicate, 
all they want to do is exclude the competition. 
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certifying that a particular implementation conforms to the 
standard. 

Only with formal recognition will PASCAL be adopted by 
large conservative organizations and selfish vendors. 

There is danger is having a committee for this pui^pose. 
When COBOL was being designed two committees were formed. Since 
the problem of business data processing was regarded as so big, 
one committee was asked to deliver a quick interim report to 
use to 'make do'.' The second committee was to solve, the DP 
language problem. The first committee report is in - its product 
was COBOL. We are still waiting for the long range committee's 
report. 

One final word on previous failures. The new FORTRAiN is an 
obvious disaster; the PL/I standard is an abomination. We can 
do better! We need be neither upward compatible with previous 
errors nor a vendor's puppet. We can do it right if we get 
together and try. 

Software Tools for PASCAL 



PASCAL implementations for new environments are occurring 
with ever increasing frequency. As PASCAL is used for more and 
more production programming, it is important that a universal set 
of ancillary software tools be agreed upon. Some of these tools 
can be defined in an environment independent way so that when 
written in standard PASCAL they can become part of a universal 
PASCAL software development facility. 1 here propose an initial 
list. With PUG membership help the list will develop into a 
working specification and a powerful set cf programming tools. 



PASCAL Compilers 

Currently there exist PASCAL compilers which produce absolute 
cede, relocatable code, macro code (PASCAL- J) and interpreted 
code (PASCAL-P). Portable versions exist ( PASCAL- P and PASCAL-J). 
Compiler trunks exist. A standard PASCAL subset (PASCAL-S) exists. 

For compiler writers there should be a standard PASCAL 
language test set. This universal set of PASCAL programs would 
exercise new PASCAL compilers and help implementors gain 
confidence in the correctness of their compilers. 

An interactive interpreter should be developed. This 3ystem 
would provide interactive symbolic run time debugging facilities: 
breakpoints, interactive dumps, etc. It should be easy to do 
better than PL/l's Checkout compiler. 

The Lecarme and Bochmann compiler writing systems are also 
important tools for any shop engaged in language development. 
Source Program Tools 

Wl rth has written a cross reference program . Perhaps, if 
the variable names were improved, a standard version of this 
program could be among the software tools. A formatter or 
"pretty printer" is essential for producing documentation quality 
listings. Kike Condict's might be a good starting place. 

A code instrumenter is a very important debugging and 
refining tool. Instrumenters insert statement counters or timers 
so that reports of relative usage of code can be made. An instrumenter 
is invaluable in optimizing programs. 

A high level macro preprocessor would also be a valuable 
facility. 



CO 

<— ) 

3> 



m 
20 



CD 



o 



GO 

m 



CO 

cr> 



CD 



4=> 
O 



10, 



S ou r c e Li b ra r 1 e s 

The CJC source library ■ utility program UPDATE .is currently 
used for distribution of the SCOPE versions of PASCAL. It seems 
to me that a mini- vers! on of UPDATE (with only sequential program 
libraries) could be implemented in PASCAL. This would help 
standardize the distribution of PASCAL tools, (incidentally, 
CDC's UPDATE is the best source library system I have ever seen,. 
I think its quality should be emulated.) 

For truly large systems (30,000+ lines) a source code data 
base is desirable. Such a system keeps track of which programs 
access what data and provides for standard file and record 
descriptions among programs, etc. I understand such a system for 
PASCAL exists but is a deep dark military secret. 
Documentation Preparat i on 

W. Burger implemented part of Waite f 3 PLAP in PASCAL. We 
need a universal PLAP- like tool to maintain manuals and other 
documentation in machine readable form. Justification and 
hyphenation and facilities for producing high quality printing 
in upper and lower case should' exist . PASCAL documentation 
should be distributed in machine readable form xor ease of 
publication and distribution. 
Object Program Facilities 

Wurk is now in progress on programs wnich load PASCAL 
absolute oinaries. Facilities for overlay processing snouid 
be provided. Automated aids which help create effective overlay 
structures should be provided. A binary decoder i.' also a useful 
tool. 
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Othe r Prog r ams 

An efficient table processor with facilities like COBOL 
Report Writer would be desirable. Current work on PASCAL data 
base management systems , mathematical function libraries , and 
computer aided instruction systems augur the day of increased use 
of PASCAL in business, engineering, and education. In the area 
of function libraries (for mathematics or business), facilities 
shouid be provided for not only linking in binary modules but 
also for including source modules. 
Conclusions 

Obviously, where environmental conditions permit we should 
have a universal PASCAL program implementing each software aid. 
Where the environmental factors prevent this, we should seek to 
provide a standard user interface to the desired functions. 

Conclusion 



The ideas presented in this paper are perhaps still ill-formed. 
They are meant as a starting point for serious discussion. I hope 
there will be reaction and feedback from PUG members. 



In my opinion, merging programs at the source level is to be 
preferred to binary level linking. PASCAL compilers are 
typically faster than linking-loaders . 



(*Received 10/12/76*) 
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THE CASE FOR EXTENDING PASCAL'S I/O 

Michael Patrick Hagerty 
Abt Associates Inc. 



With the introduction and subsequent increase in popularity of PASCAL, 
. a number of papers concerning the language, its features and deficien- 
cies, have appeared in various journals and newsletters. Champions of 
the language have extolled the virtues of its structure and unambiguous 
grammar using both example and theory as justification of its useful- 
ness. PASCAL critics, on the other hand, have questioned the claim 
of the proponents that PASCAL will replace FORTRAN, pointing to the 
inadequacies of the language in several areas. Wirth (1974) defends 
the absence of certain "favorite features" as necessary to avoid 
inefficient programming solutions or reliance upon features which are 
contrary to the aim of clarity and reliability. When the features being 
debated refer to the flexible input of large amounts of data, the 
critics hold the stronger hand, and with much justification. 

As a user of PASCAL in an environment where large files of data are 
the rule rather than the exception, I find the argument that PASCAL'S 
native input facility is sufficient to be without merit. Much of the 
data analyzed at AAl is produced by the Bureau of the Census or other 
government agencies and is available only in fixed-format records in 
multi-file volumes. The absence of a formatted input capability is 
not merely inconvenient in this instance; it is self-defeating. Several 
alternatives have been adopted as stopgap measures, including the use of 
FORTRAN subroutines to handle all read operations. However, it is ob- 
vious that if PASCAL is to become one of the more common languages, it 
must possess an I/O capability which is useful to those who process 
large amounts of data as well as the compiler writers. 

To gain insight into what is required, it is first necessary to examine 
the deficiencies in PASCAL from the data analyst's point of view. The 
following list represents a minimal set of those deficiencies: 

t PASCAL I/O is asymmetric in that no READ operation exists which 
is the inverse of the formatted WRITE. 

• PASCAL I/O is further asymmetric in that certain types (ALFA 
and BOOLEAN) may be written, but cannot be input using the 
native RtAD procedure. 

t Although the most powerful facet of PASCAL is its structuring 
facility, there exists no simple,* direct method of transmitting 
RECORDS to and from formatted textfiles. 

PASCAL requires the inefficient use of data storage media by 
not allowing the user to maintain his data in multi-file volumes. 
Only data between the portion immediately addressed upon RESET 
and the first EOF can be examined. 
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major portion of data collected in both the business and research 
ties is stored as formatted files of records more or less card- 
ize, the absence of a feature which will allow the direct read of 
c columns rather than f reef i eld is an extreme shortcoming. The 
of formatted files was not made only for convenience, although 
i lability of this feature in other languages did encourage its 
t does require space, disk or tape, to store large amounts of 
nd the requirement that each variable be separated from its neigh- 
a blank(s), gobbles up more space, and therefore costs more. 
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If it were only the very large data bases which were formatted, an argu- 
ment could be advanced for special, custom-tailored I/O for these appli- 
cations. This position loses ground when considered in light of most 
applications packages which allow both form of input. AAI is a yery 
heavy user of the SPSS and other statistical packages. Within the past 
year, the f reef i eld input facility of SPSS has been exercised only twice: 
once to test that it worked correctly; and once again on a problem with 
only ten cases. With any survey of over 10-20 observations, it is also 
much more economical (and accurate) to have the data collected in fixed 
format without blank delimiters. 

In the present situation, each user community is left on their own to 
develop and implement as part of their library, a formatting reader 
which meets their own needs. The upshot of this, as clearly described 
by Eisenberg (1976), is that PASCAL will become another BASIC in the 
area of I/O. As most users are aware, BASIC programs from one system^ 
have a yery low probability of running under another system as each 
manufacture, or vendor, chooses to implement I/O in a slightly differ- 
ent manner. The computing world can well do without this form of chaos. 

Turning to the second area of concern, we find that there exist certain 
types of variables in PASCAL which possess a unique property: although 
we may print them out to see what value they are assigned, it is not 
possible to read them in directly. ALFA and BOOLEAN are examples of 
these types, however other implementations may be busy installing 
additional varieties. In languages which preceeded PASCAL, an iron- 
clad rule existed for I/O, "If you can write it out, you can read it 
back in." 

The third mentioned deficiency is directly related to the first two. 
It is incongruous that a language as well structured as PASCAL would 
fall into the trap of requiring the user to transmit the elements of 
his wel I -structured records element by element. This deficiency is 
magnified by the lack of a defined formatting facility for input, the 
existence of the "special" types, and the absence of a formatting tool 
which would tie the size of the individual elements to the order within 
the record itself. FORTRAN has FORMATS ; COBOL and RPG have PICTURES; 
and PASCAL has nothing comparable. It has been rumored that one im- 
plementation of PASCAL uses FORTRAN FORMATS, although this hardly seems 
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to be the optimum solution to the problem. What is needed is a fresh 
look into what it means to tie a format specification, even if it im- 
plies f reef i eld, to a given element of a structure. Unlike FORTRAN, 
it should be capable of diagnosing at compile time attempts to read 
or write integers with decimal points and otheV such errors. 

The fourth deficiency is representative of the attempt to stay clear of 
defining what constitutes the implementation of files within the context 
of a system. By requiring that all data sets processed by PASCAL con- 
sist of one file, the interface between various systems is kept simple. 
Unfortunately, this requires the user to either keep one file on each 
tape or disk library, or copy off a single file from the multi-file 
volume to satisfy PASCAL. Keeping partially filled tapes and/or copying 
desired files does require added expense. 

The remainder of this paper will be devoted to several recommendations 
which, if adopted, will remedy most of the problems in the area of I/O. 
The form of the recommendations will be to first present what the 
construct will look like, followed by an explanation of how it is to 
be implemented. Each of the constructs will be based within the scope 
of the following declarations: 

CONST NOT = (* Number of Characters Per Word - ALFA TYPE *) 

VAR A: ALFA; 

B: BOOLEAN; 

I: INTEGER; 

T: TEXT; 

F: FILE OF arbitrary type; 

N: INTEGER; (* number of characters read or written *) 

D: INTEGER; (* number of places to the right of decimal *) 

READ (T, I:N) will convert N characters beginning with the current 
position of the file T to INTEGER and store the result in I. 
Leading blanks are to be treated as zeros, but trailing or imbedded 
blanks represent an error and should be diagnosed as such. The 
number may be signed or unsigned. 

READ (T, R:N:D) will convert N characters beginning with the current 
position of the file T to REAL retaining D characters as the 
fraction. Blanks before the whole number and following the fraction 
are to be considered zeros. Imbedded non-digits are errors. The 
only exception is that a decimal may be punched in the data which 
would override the D specification. 

READ (T, B) will read a BOOLEAN variable B freefield from the file T. 
TRUE and FALSE will be the allowed character patterns. 



REAU (T, B:N) will be expected to find the characters TRUE or FALSE 
within the next H character on the file T. Where N is less than 
5, only the first N characters will be matched. 

READ (T, A) will store a left-justified ALFA of at most NCPW characters 
in A. The variable will begin with the first occurring non-blank 
character on the file T and continue with characters until the 
number of characters is equal to NCPW, a blank character is en- 
countered, or EOLN(T)=TRUE. While spanning leading blanks, EOLN 
will be ignored. EOLN will be cleared on return from the proce- 
dure if it terminated the transfer of characters. 

READ (T, A:N) will store the following N characters from the file T 
left-justified in the variable A with blank padding out to NCPW. 
No more than NCPW characters may be transferred. EOLN will, as 
an installation parameter, cause a normal termination with added 
blanks out to NCPW. 

OPENR (F) will cause the system to RESET a file without rewinding it. 
This allows the user to position the file before executing the 
PASCAL program. 

OPENW (F) is the non-rewinding version of REWRITE. 

PUTEOF (F) instructs PASCAL to write the output buffer, followed by 
an EOF, and invoke OPENW beyond the EOF. PUTEOF is the tool for 
creating multi-file volumes, a PUTSEG for EOFs. 

GETEOF (F) will cause an End-of-File to be read (skipped), with the con- 
current resetting of EOF(F) to FALSE. OPENR(F) will then be invoked 
to open the file past the EOF. If two contiguous EOFs are detected, 
this will imply the end of the volume, and EOF(F) will be reset to 
TRUE upon return from GETEOF(F). If EOF(F) is not initially TRUE, 
data will be skipped until the EOF is encountered, and the normal 
processing of GETEOF will continue. 

GETEOF (F, N) instructs the system to skip N EOF marks on file F. When 
the N parameter is specified, GETEOF is analogous to GETSEG(F,N), 
with file instead of seqment marks. GETEOF(F) is equivalent to 
GETE0F(F,1). 

The above eleven proposed extensions to the language are directed to 
overcoming three of the four mentioned deficiencies. The code necessary 
to implement these features is simple and readily installed in any com- 
plete implemention of PASCAL. (As an example, although trivial, "the 
code for reading ALFAs is included as an Appendix). The observant 
reader will notice that no attempt has been made to provide a workable 
solution for the third problem: formatted and freefield I/O for structures. 
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It is conceivable that a mechanism can be devised which is compatible 
with the syntax, grammar and structure of PASCAL, and will allow the 
separate assignment to different elements in a structure of specific 
formats. After giving the matter much thought, I am at a loss to 
produce a new and uniquely appropriate scheme. It appears at first 
blush that some hybrid of PICTURES and FORMATS might work. 

For want of an adequate solution, we at AAI have adopted a strategy 
which we know to be flawed. It is unacceptable as a solution to the 
problem of records and textfiles because it simply ignores the exis- 
tence of textfiles altogether. By specifying a single word format 
descriptor for each element in a record, it is a simple matter to 
have a procedure decode a whole record quite efficiently. By building 
arrays of 



TYPE FORMAT = PACKED RECORD 

FTYPE: (ALFA, BOOLEAN. 

DSI'ZE: 0..777B; (" 

NSIZE: 0..777B; {* 

STBIT: 1..777777B; (* 

NWORD: 1. .777777B ( s 
END; 



INTEGER, REAL); 
DECIMAL PLACES *) 
NUMBER OF CHARACTERS *) 
STARTING BIT IN WORD *) 
NUMBER OF WORD IN RECORD *) 



of the same size as the records to be read, filling in the five elements 
with appropriate descriptors, and passing that array, along with a 
segment of text already read, the text can be converted. 

The procedure we use has four parameters: a vector of characters; the 
FORMAT array; the resultant decoded RECORD of data; and an integer which 
specifies the number of elements to decode. For the sake of efficiency, 
the routine was coded in the assembly language of our machine. The only 
trick is to manage to get into PASCAL a whole segment of text to decode. 
This is accomplished by fudging the I/O buffer allocated by PASCAL and 
allocating a array on top of that buffer. Data is then read into that 
buffer, and decoded directly out. CDC, as well as most other manufac- 
turers, provides a powerful read facility which will initiate a read 
of a specified number of words (or bytes), and read until either the 
list is satisfied, or the record on the input device is depleted. It 
is this feature which I would propose to be an implementation dependent 
feature. 

READBUF (F, X, N) will initiate the reading of N items of X (which is 
and array with at least N elements) from file F. This operation 
merely initiates the read, but does not guarantee its completion. 

WRITEBUF (F, X, N) is the inverse of READBUF and initiates the write 
of N elements of the array X. Once Sgain, completion is not 
guaranteed. 



COMPLETE (F) forces the system to complete any pending I/O operation 
on file F, entering a recall state if necessary. 

BUFLENGTH (F) is a function which will return an integer representing 
the number of elements actually transferred on the last operation 
on the file F. It is clear that BUFLENGTH should not be used until 
COMPLETE has forced the end of the operation. 

These additional, implementation dependent, features allow the machine 
to optimize its I/O operations and give the user the opportunity to 
overlap some independent processing while the machine attends to the 
task of moving data. 

The sophisticated user should recognize that while the suggestions made 
in this paper apply most directly to the sequential access of large 
amounts of data (the issue of greatest importance to AAI), no attempt 
been made to come to grips with the host of other access methods. Files 
of e\fery variety, indexed, keyed, and hashed, exist; the need now is to 
propose the manner in which PASCAL will address them. Given a language 
with data structures as powerful as PASCAL, no effort should be spared 
to provide an equally powerful set of I/O operations. The challenge is 
to devise an implementation independent scheme for doing it. 
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<»$T-«P-,E*,U*.XO KEAD ALFA <LEFT- V MST IF I ED) FrEEFIELD. HAGERTY *) 

PROCEDURE ROA (VAN F : TEXT; VAR A! A|_FA)J 

CONST NCPW = lul (* NUMBER OF CHARACTERS PFR WORD «) 
VAR I: INTE3ER? 

CHBUF: ARRAY[ 1..NCPW] OF CHAR; 

BEGIN] 

IF EOF(F) THEN 

BEGIN MESSAGED* TRIED TO READ PAST FOS/EOFEM HALT END; 
WHILE (F* = = E) AND (NOT EOF(F)) DO GET(F); <« SPAN LEADING "BLANKS *) 
IF NOT EOF(F) THtN f » COLLECT CHARACTERS FOR ALFA #) 
BEGIN 

i:=o; 

REPEAT 

I : = I ♦ J ; 

CH3UFCI 3 :=Ft; 
GET(F) ; 
UNTIL <F*== E) OR (I=NCPW) OR EOLN{FH 

IF EOLN(F) THEN GET(F); <* CLEAR EOLN FLAG IF SET ») 
WHILE I<NCPW DO (« FILL REMAINDER OF WORD WITH BLANKS ♦) 
BEGIN 

I: = I + n 
CHBUF[I]:=:E = 

end; 

PACK (CHB«JF»1»A) 
END 
END (* RDA ») ; 

(*$T-tP-,e*tU*>X0 READ =NCE COLUMN ALFA IN FIXED FORMAT. HAGERTy *) 

PROCEDURE FRDA (VAR F: TEXT; VAR A: ALFA; NCI INTEGER)? 

CONST NCPW = lu? (« NUMBER OF CHARACTERS IN A WORD *) 

VAR I: integer; 

CHBUF! ARRAYt 1..NCPW] OF CHAR: 

BEGIN 

IF EOF(F) THEN 

BEGIN MESSAGED* TRIED TO READ PAST EOS/EOFEM HALT END? 
IF (NC<1) OR (MC>NCPW) THEN 

BEGIN MESSAGE (=* AlFA FIELD WIDTH ERRORE); HALT END; 
IF NOT EOLN(F) THEN (» COLLECT =NCE CHARACTERS ») 

BEGIN 

i:=o; 

REPEAT 

I : = I ♦ » ; 

CH3UFI I ] !=Ft| 
GET(F) ; 
UNTIL (I=NC) OR EOLN(F) ; 

WHILE I<NCPW DO (♦ FILL RFMAINDER OF WORD WITH BLANKS ») 
BEGIN 

I J=I*15 
CHBUFCI] :== = 
END? 
PACK (CHBUF»1»A) 

ENn; 

END (♦ FRDA *) ; 
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MIXED LANGUAGES 

Here is the focus of the survival af PASCAL. If it is possible far 
programmers to access and use the vast library of FORTRAN mathematical 
routines that have been developed, then there is hope that the 
scientific community might be encouraged to transfer their skills and 
effort into PASCAL from FORTRAN. A tremendous benefit, and greatly to be 
desired. If this is not possible (to mix languages) then even this slim 
hope must fade away. The inertia and Ecological success of FORTRAN is too 
great for any naive competitor to survive and thrive. 

I note many PASCAL compilers produce assembly code for their machine. 
Shades of IBM70^0! Still, the approach does allow mixed languages at 
little cost, but some attention must then be paid to Ci) efficiency, and 
Cii) ease of use of the joint system. 

On the Burroughs B6700, the problem is much more significant as no 
assembly language exists. (For those who marvel at this, know that no 
computing centre director would want one for the security risk it would 
be CBS700 integrity relies on software), and know that the structure of 
the executable code file would require an elaborate assembler to specify 
all that is necessary-..) Burroughs Algol is the lowest level of the B6700. 
Consequently achievement of mixed languages requires either compilation 
into Algol (disregarded!) or the construction of structured cade-files 
that are quite, incredibly complex by the standards of monolithic machines. 
The binder in fact has to be able to re-arrange code (especially in the 
outermost block) for own and pre-defined objects; associate names; 
check parameter compatibility; and all this for ALGOL /"ORTRAN/PL/I /COBOL'' 
at least. 

Nevertheless, even in this case, the achievement of mixed-language programming 
must be attempted. Even more must this be the case in simpler situations; 
the only exceptions being mono-language systems such as Brinch-Hansen's. 
And these are not addressed to the same purpose as viable general-utility 
compilers. 
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PORTABILITY 

It is irroortsnt to realize that standardization is not a good in itself; 
the present benefits to computer science of standardization are 

(1) transferability of skills betueen compilers, 

(2) portability of programs written in standard languages, and 

(3) exchange and development of compatible compilers is made more easy. 

It must be realized that the semantics of the language is quite as important 
as the syntax in realizing objective (2), and in this regard there are 
any number of difficulties in standard PASCAL. 

First of these is perhaps character set. Except for those computers that 
persist with 6-bit characters, the EBCDIC and ASCII character sets must 
be regarded as the de facto standards of the industry. All PASCAL compilers 
should have the capability of working in either ( preferably both ) of these 
two character sets. The implications are that no-one is justified in 
inventing a new character set, nor in allowing any other character set to 
be used unless it is a. firm committment by the computer/operating system; 
and that even in CDC and other 6-bit machines an effort should be made to 
provide ASCII and EBCDIC characters. I can think of no more common 
portability trap than that of ignoring character collating order. Pascal-P 
was caught. 



kclusiop: of source text 

The 86703 compiler has a feature (as with all Burroughs compilers) for 
including source text from a named file in the compilation. The included 
text may be, but is not usually, listed. It may include further included 
files, up to nesting depth defined by the number of file buffers reserved . 
(in the PASCAL compiler: a depth of 6). In fact this- is used as a structuring 
aid in the BS7Q0 PASCAL compiler source, which consist of some 20-30 files 
(some with alternatives) linked into a tree-like structure by inclusion 
references. The facility is also useful for including library routines 
(in PASCAL source of course) as in special i/o routines, mathematical 
routines, graph-plot routines, etc. It may postpone the need for the use 
of relocatable binary or linked versions' of PASCAL programs... 

The B6700 construct is a compiler option: it appears on a single line 
which, begins with a $, and has the following syntax: 



> INCLUDE - 



— >- filename 



H 



sequencenumberrange 



_T 



Examples: 

SINCLUOE PACKABE1 
■ IliMCLUDE ARTHUR/STANDARD/TYPES 30000-60000 



GO 

5=» 



m 



CD 



m 
20 



Another, not so obvious, is the practice of allowing any-length identifiers, 
but permitting only the first few n characters to be significant ignoring 
the tail. If a program is compiled on a computer with true any-length 
identifiers (e.g. B6700) , then it is quite on the cards that it will be 
compiled incorrectly by some other computer without warning, as if the 
names are TEMPATT0P0FKILN , TEMPATT0P0FFLUE. No, identifiers must be 
true any-length , or fixed up to a length n with at the very least a mandatary 
warning or better an error thereafter. 



Quite clearly, such a construct in PASCAL could also be embedded in the 
compiler option Ulirth has implemented, if only it were not so restrictive 
in syntax. I would commend such a facility to all PASCAL compiler-writers, 
preferably adhering to the above syntax. The default should be to omit 
listing the included text. 
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There are many more portability traps which act so as to limit the 

real portability of programs written on one computer to quite a long way below 

that which is achievable at the present state of knowledge. They require 

more attention in the case of PASCAL. I find it infuriating to receive a 

program that the author claims is "portable" only to find that he or she 

is obviously not aware of the most obvious' requirements for portability. 
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FILES 



Files are PASCAL'S biggest problem. In a modern context, PASCAL'S files 
are an anachronism. PASCAL should have access to random-access files 
as well as sequential; should be able to communicate with terminal devices 
as well as card readers and line printers; should be able to at least 
specify file attributes; and should have a record-oriented i/o subsystem. 

On top of this files da not fall into the same class as other V/AR objects, 
since for the most part their life (extent) is not. limited to the extent af 
the program or a procedure thereof. They may be already existing (in which 
case the declaration is mare of the nature of a specification), or may live 
on past the program's death (and often have to conform to external 
requirements such as line-length). 

Therefore all normal WAR operations on files should be carefully avoided. 
The assignment and comparisons on files should be regarded as absolutely 
meaningless, as should possibilities such as arrays of files, or records 
containing files, and other similar nonsense. 

The B6700 implementation will include attribute lists in the FILE type 
declaration (whether in the TYPE or WAR part) according to the following 
syntax: 



->= FILE ->-. 



ibutelist-*)-* 



* DF 



L* ( —^ machinespecif icattrib 

Examples: 
VAR 

INPUT (KIf\lD=READER) OF PACKED ARRAY [0;79] OF CHAR; 
CODE (KIIMD=PACK 1 ,TITLE=EXECUTA3LE/C0DEAEST,Uf\IITS=liJ0RDS, 
MAXRECSIZE=30,BL0CKSIZE=300,MYUSE=DUT) 
OF SECTORRECORDTYPE; 
The attribute list probably has to be machine-specific at the present state 
of operating systems. The declared size of the record of the file is 
checked for compatibility with any specified attribute. 

All 86700 files are automatically allowed to be accessed sequentially 
or randomly, so this question does not arise specifically. Environment 



ri.e -j and atcnb'.jt 



snges can bo done via calls on the operating sys 



STANDARDS 

Adherence to the PASCAL standard, interpreting this to mean the language 
defined in the Pascal Report, and the axiomatic definitions thereof, must 
be a very high priority of any PASCAL compiler writer/ma intainer. There 
are nevertheless several sticky problems which face any person in these 
categories. Let me expose them. 

1< There is the question of whether to implement a strict PASCAL, or to 
extend it with various features. Of course there are some areas 
where PASCAL must be extended (see later) , but every extension provides 
a user temptation and reduces portability of the resulting programs. 
This works towards implementing PASCAL as she is defined, and that 
alone. 
2c There are the problems associated with undefined parts of PASCAL; for 
example the elaboration of a CASE where the case expression evaluates 
to a value not matched by any label. A compiler writer has to do 
something, and these flaws or loopholes in the definition are left to 
individual discretion. 
3. There are places in PASCAL where the language is seriously deficient; 

primarily in treatment of files and i/o. Individuality here is necessary 
but can be seen to be clearly tending towards the Algol and BASIC 
messes. 
k* There are places jn the PASCAL definition where the antecedents of 
the present state show through, jn an unwarranted manner. Examples 
of these are (1) the CDC influence in the curious PROGRAM construct 
(often unnecessary, and deriving from CDC FORTRAN) , the use of .. or : 
from Algol in array declarations (when TO is mare explicit and less 
obscure), and the insistence on FORTRAN'S archaic control character 
at the start of a printed line! 

Objectively, or as far as I am capable of it, it seems to me that PASCAL 

has in fact been frozen too soon, before the defects have had a proper 

chance to be eradicated. It is therefore of prime importance that 

some procedure be adapted whereby evolutionary change in the language 

can be controlled, otherwise proliferation of dialects is inevitable. 

Some of the afterthoughts should be recognized as such, and removed from the 

province of the standard defining document. 



(♦Received 10/31/76*) 
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OPEN FORUM FOR MEMBERS 

(SHORT, IftrOMAL CORRESPONDENCE) 

LEHIGH UNIVERSITY 

BETHUEHEM. PENNSYLVANIA IBOI5 



IN REPLY PLEASE QUOTE: 



DEPARTMENT.OF MATHEMATICS 
CHRISTMAS-SAUCON HALL 3* ! 4 



July 23, 1976 



Mr. Andy Mickel 
PASCAL Users Group 
UCC: 227 Exp. Engr. 
University of Minnesota 
Minneapolis, MN 55^55 

Dear Andy: 

What happened to that new PASCAL release announced 
last March? 

One of my students has just completed a CAI system 
in PASCAL. It features a lesson creation language which 
has excellent expressive ability (it is possible to create 
structured CAI lessons with it). The compiler for this 
language is quite efficient. Its output code is interpreted 
by a small (12.5Kq words) PASCAL program. The interpreter 
features good run°time debugging aids which in many ways 
resemble PASCAL'S FMD. 

In addition to the lesson compiler- and .interpreter, 
there is an object lesson decoder and student monitoring 
facility. The student monitoring routines record and 
report individual student scores. Lessons can also be 
set up which administer tests. The monitoring facility 
reports a trace of each student's lesson sessions question 
by question. The system keeps track (on a permanent file) 
of each student's status and can be used to sequence 
students thru a series of lessons and tests. 

In total, the system is the most versatile and 
efficient CAI system I have ever seen. To a great extent 
the viability of the system can be attributed to the fact 
that it was built with PASCAL. Should we write up the 
system for the Newsletter? 




Richard J. CIchelli 
(*Note: The student mentioned above is PUG member David Englander.*) 




TELEPHONE: 692 J49I 
692 1122 
EXT 3491 



UNIVERSITY COMPUTING CENTRE 

THE UNIVERSITY OF SYDNEY 



NSW 2006 



Pascal User's Group C/- Andy Mickel / 
University Computer Centre: 22 7 Exp Engr. 
University of Minnesota, 
Minneapolis, MN 55455 
U.S.A. 



30th July, 1976 
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Dear Andy, 



Please accept an application for membership of the Pascal 
User's Group in my name. A cheque for $US4 is enclosed. 

Our Computing Centre provides a service to the University 
and to some outside users. For the past 18 months we have 
been developing some of our applications programs in PASCAL. 
We have found a significant improvement in the rate of 
production of reliable programs. It is, of course, a 
pleasure to write in. 

The PASCAL compiler here is maintained by the Basser 
Department of Computer Science who make extensive use of it 
for undergraduate teaching and research computing. As 
we have to continue to provide software products across 
hardware changes, we are interested in the transfer of 
PASCAL to new machines and in program writing tools. No 
doubt your Center has the same concern. As we have only had 
our CYBER 72-26 for two years it will be some time before 
we may have to face the problem. 



Yours sincerely, 
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Brian G. Rowswell 
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2512 San Gabriel St. 
Austin, TX ?8?05 
1? Aug 1976 



Andy Mickel 

Univ Computation Center 

Univ of Minnesota 



Dear Dr. Mickel, 
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COMPUTER AND INFORMATION SCIENCE 

GRADUATE RESEARCH CENTER 

(413) 545-2744 
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August 31, 1976 



I would like to join the PASCAL users group, and receive 
your newsletter, 

I am a doctoral candidate in anthropology, and my uses of 
PASCAL are for organization and analysis of data on language 
acquisition and on cognitive variation. Since programming 
for anthropological applications usually involves handling 
odball data (when the study is not a simple statistical one), 
the ability to strucu-tre that data has a rather liberating 
effect on one's programming! 

However, I have found the lack of formatted read capability 
rather annoying at times, and I v/onder if other users feel 
the same way. It would certainly not be difficult to add 
this capability to the compiler in such a way that it would 
provide upward compatability with the Jensen and V/irth (197*0 
standard, for examples 

READLN(f, xl:wl, x2iw2, x3iw3): 

where x n is a variable of type integer, real, or packed array 
of char. For blank: fields, integer and real variables are 
assigned the value zero. Variables formatted to positions 
past the end of line should be assigned zero (or blank in 
the case of strings) or there would be transportability 
problems between systems which truncate trailing blanks and 
those v/hich do not. Real numbers such as .05, -.3 should 
not cause RDR to halt the program (in formatted or freefield 
reads)! Honestly -- you'd think ETH never writes programs 
which have to read the output of Fortran programs (i.e. 
statistical packages) . 

I'm looking forward to seeing my first PASCAL users group 
newsletter — tell me if there are any dues or anything. 



Sincerely, 



m 




Willett Kempton 



OPEN FORUM FOR MEMBERS 



Dr. Andrew Mickel, Editor 
University Computer Center 
227 Experimental Engineering Bldg. 
University of Minnesota 
Minneapolis, MN 55455 



Dear Andy: 



As we discussed on the phone, enclosed is an item v/hich we would 
like to have included in the next issue of the PASCAL Newsletter. 

Also, enclosed is a copy of the actual prettyprinting program 
and documentation, which is for your information. 

We have looked at the prettyprinting documentation from Lehigh and 
it is not at all along the lines of our prettyprinting program. Let us 
keep in touch. 

Sincerely, 



-2/ y^^L J 

Henry ¥. Ledga 
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¥. Led gar d 
Associate Professor 
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(SHORT, INFORMAL CORRESPONDENCE) 



( u ^^ WEST TEXAS STATE university 
y£kl7 SCHOOL OF BUSINESS CANYON, TEXAS 79016 

DEPARTMENT OF COMPUTER INFORMATION SYSTEMS 

September 13, 1976 



PASCAL User's Group 
0/0 Andy Michel 
UCC: 227 Exp. Engr. 
University of Minnesota 
Minneapolis, MN 55455 

Andy: 

Some tine ago you sent to all PUG members a set of corrections for 
the PASCAL User Manual and Report, Second Edition. In the process 
of moving from Drake to West Texas State I have buried my copy in 
stacks of yet unpacked papers. Would you please sendee another 
copy. I would appreciate such. 

We are in the process of getting PASCAL up and running on our DEC-10. 
I am working without letup on the process of converting to PASCAL 
some rather open-minded colleagues. I will use PASCAL as the vehicle 
language in the data structures course this spring. (Is there any 
other way to do it?) 

Do you know if anyone has yet to build a really interactive version of 
PASCAL? 



When does the first edition of the PASCAL Newsletter come out? 
looking forward to receiving it. 

Sincerely, 



I am 



H. P. "Duke" Haiduk 
Assistant Professor 
Computer Information Systems 



UNIVERSITE DE NICE 

LABORATOIRE D'INFORMATIQUE 

PARC VAUROSE 

06034 NICE CEDEX 



Nice, fe 16 th SEPTEMBER 1976 
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Pascal user's Group 
c/o Andy Mickel 
University Computer Center 
227 Exp. Engr. 
University of Minnesota 
Minneapolis, MN 55455 
U.S.A. • 



L 



- Ik ■■;:•• Andy : 
I read with much interest the first newsletter made under your responsibility, 
and I was very impressed of the vast amount of useful informations you 
managed to pack in it. One problem afraid me : at £>/ 1.31 for postage costs, 
my fee for the group will not even cover them for one year. If you have a 
non-negligible number of overseas correspondents, this could be a problem. 
Would it not be good to have a European re-distributor, who could make as 
much copies of the newsletter as necessary and send them throughout our 
whole old continent ? He could also collect fees and keep the part needed 
for his own costs. This would be an extension of the suggestion made by 
Judy Mullins of Southampton. I am not suggesting that I could do this work, 
since we have no really good copying facilities in Nice, but maybe somebody 
else could be contacted in a wealthier University. I think that Pascal is a 
language which is equally popular on both sides of the Atlantic, and that 
it would be a pity not to take advantage of this exceptional situation. 
The rest of the present letter is devoted to some remarks , comments and 
precisions urged on by the reading of the newsletter. Some of them may be 
of interest for other Pascalers and merit publication in the newsletter, 
but I think it would be better that you db selection and morever a rewriting, 
since I know my English has much deteriored since my departure from Canada. 

Pascal User's Group session at IFIP- ' 77 : in the same, spirit as 
the remark before, I think it would be very interesting to have a world 
meeting after the many national meetings in USA, England, France (more 
details below), Switzerland, etc. It should be possible to arrange something 
with the local organizers in Toronto, or through a TC 2 member. Since IFIP 
is a very formal organization, it should be useful to search for some 
arrangement as soon as possible- 
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Standard Pascal book by Bill Atwood : I am somewhat afraid by 
mis title, arid I will write separately ro Bill. What is exactly 
Standard Pascal, I do'nt know, and I think it should be very dangerous 
thai anybody (but Wirth) could say that his own idea of the language 
is 1 he standard, without any discussion with the community of Pascalers. 
Many people have different ideas on the subject, and 1 say more on the 
subject selow. 

News about Pascal in France and other French-speaking parts 
of Europe (Pierre Desiardins could say much more than me about the 
French- speaking part of America) : Pascal is used in some important 
or smaller Universities as a vehicle for teaching programming and 
writing software, especially in Paris (Institut de Programmation) , 
Toulouse (Universite Paul Saba tier), Bruxelles (University Libre), 
Lausanne (Ecole Poiytechnique Federale), Mbntpellier, Nice, Neuchatel, 
etc. Some important Universities (Grenoble, Rennes) do not use it 
because they have made high investments in either Algol W or Algol. 68, 
which are much better tools than Fortran and therefore stronger 
obstacles to the shift to Pascal. Implementations of Pascal have been 
made in Grenoble on the IBM 360, Paris on the CII Iris 80 and 10070, 
Neuchatel on the IBM 1130, and one is being made in Nice on the CII 
Iris 50. More details follow in the "implementation" part of the 
present letter. A two-days meering about Pascal rook place in Nice one 
year ago. Six + y persons from France, Belgium and Switzerland attended. 
You will receive by separate mail the text of the majority of the papers 
which were presented. Additionnally, there were panels about the use 
of Pascal in teaching, its implementation and its changes, or extensions. 
I plan to organize a similar meeting in May or June 77. 

Aboi it t he pa per by R i char d C ic h* ■ 1 ! 1 : I think .it would 1>- a 
very useful policy to request of people sending Pascal programs to 
write them in the publication language and not in any particular hard- 
ware or implementation language. By "publication language", I mean the 
form 'used in both Wirth 's books and in the Pascal reports from Zurich : 
fir- use of lower-cas^ letters, underlined keywords, use of every 
simple and aesthetic available characters, such as {and } for comments, 
<, ^, i and so on. By "hardware or implementation language", I mean the 
form used in Jensen & Wirth' s book (because of limitations on the 
character set) and or - , every implementation : generally only upper-case 



letters, ( * and * ) for comments, <* , >- , v> and so on. I think the 
publication language is the only truly readable and aesthetic form, and 
that every implementation should be free to give its own interpretation 
of the characters which are not available on its particular hardware, 
provided it conforms to the general rules stated by Wirth himself. In 
fact, any implementation language which can be translated into another 
one by means of a one-page Pascal program should be acceptable, and this 
includes national variants for key-words . In Cichelli's paper, examples 
in the text generally conform to the publication language, comments 
excepted, but figure 1 does not underlines keywords and uses a character 
set not particulary readable, and the complete program seems to me a good 
example of what should be never done : only upper-case letters, no 
underlined keywords, _ for strings, /* and */ for comments as well as [-► 
and * , and so on. I know well that it is very difficult to have any 
secretary to type correct program texts, and that is probably the reason 
why Jensen & Wirth' s book was typed by a computer, but it can be done 
and I think it is worth the trouble. Of course, these remarks are not 
criticisms about. Cichelli's paper, which I find very interesting and 
useful . 

About the paper by Timothy M. Bonham : , I agree about point 1 . 
About point 2, I must recognize that to critize Habermann about the use 
of "..." instead of ".." was a petty point and probably a criticism of the 
typesetter, bin I think also that, proof-reading exists for removing such 
errors. The symbol "..." itself would cause problems in some scanners, 
since it would be the only three-characters delimiter In the language. 
I have a more important criticism about the CDC 6000 compiler, which 
considers "••" and ":" as equivalent, for some historical and obscure 
reason. That is probably the main obstacle to a very simple and natural 
extension of the case statement, viz. the use of a subrange as a case 
label, by similary with the notation for sets. 

About point 3, I think that this long discussion should not 
be necessary if the distinction between publication and implementation 
language was clearly done : if you have the left arrow and like it, 
use it; but it is much more uncommon than you think, and there are much 
more Algol users than APL users on the Eastern side of the Atlantic. 

About point 4, I agree , more especially as the French version 
of Pascal keywords uses Ms and haut (up and down) as translations for 
to and downto . About point 5, I disagree, because three different syntaxes 
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for comments seem really too much. As it is, the current syntax has 
more advantages than disadvantages . Once more, however, I think that 
every particular lexical convention which may be translated into the 
standard one (if "standard" is really defined) by a one-page Pascal 
program should be acceptable (but not for- publication!). 

Pascal bibliography : my translation in French of Wirth's 
first book (Systematic programming) is at last :'n hands of the 
publisher (Masson). I expect the book to be released during 1977. 

Implementation notes : Although CII 10070 is a nickname 
for Xerox Sigma 7, the CII Iris 80 is another machine, more precisely 
an extension of the first one. Moreover, the CII operating system is 
different from Xerox and transporting a Pascal compiler from a Xerox 
Sigma 7 to a CII Iris 80 probably would not be a trivial job. 
A Pascal compiler for both CII machines has been written by Messrs. 
Thibault and Mancel of IRIA (Research institute in Informatics and 
Automatics, a French government agency), by bootstrapping the first 
CDC 6000 Pascal compiler. It has now been upgraded to accept Standard 
Pascal and to allow separate compilation, and it is officially distri- 
buted by IRIA, a case which seems unique. Its overall performance seems 
to be quite good, and it is used in French Universities which have one 
of these machines. 

The CII Iris 50 is a completely different machine, much 
smaller, and we have some trouble in Nice when trying to implement 
Pascal. Pascal-P presently works interpretatively, but it is unusable 
for programs larger than one page, and consequently it cannot be used 
as a tool for bootstrapping a true compiler. I plan to write a brief 
paper for describing the bootstrap method which will be used, and which 
seems to be a unique one. Maybe it could be done in time to be included 
in newsletter number 6 . 

A Pascal compiler for the IBM 360, which was probably the 
first one, has been done in one of the Universities of Grenoble., 
Unfortunately, the people who made it had no time nor support for 
distributing it, although it seems to have impressive performances in 
execution time (but less good in storage needed for compilation). , 
People to contact are Messrs. Henneron and Tassart (Informatique & 
Mathematiques Appliquees , B.P. 53, 38041 Grenoble-Cedex, France). 

Implementations for Pascal-P, Pascal-S and finally full 
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Pascal have been done for the IBM 1130 and are in use at the 
University of Neuohatel (Centre de Calcul, Chantemerle 20, Ch-2000 
■Ncuchatel, Switzerland). 

A complete and standard compiler for the Xerox Sigma 6,7 
and 9 has been done by Pierre Desjardins, who can give you all 
desirable information. Anyway, it seems to be a very good implementa- 
tion, especially in the domain of compatibility and conformity with 
the standard. 

I hope that some of these informations will be of interest 
to you, and that my poor English will not be a hindrance. If you 
managed to read this long letter in its entirety, thank you for your 
long-suffering. I look forward to any news. 

Sincerely yours, 
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' PAUL. MINNESOTA 55165 

l.i'iioni: ur.iu u4o-n5i* 



September 17, 1976 
Andy Mickcl 

University Computer Center 
University of Minnesota 
227 Experimental Engineering Building 
Minneapolis, Minnesota 55455 

Dear Andy, 

In response to John Eisenberg's article 'In 
Defense of Formatted Input' I would like to make the 
following remarks: 

1. Formatted I/O statements are usually wrapped 
up in a package of confusing notations which 
detract from the readability of a program. 

2. It is not clear that a system routine which 
does ord(ch) - ord('j#') would be any better 
than the user's own routine and in addition/ 
it is unlikely to respond in a flexible manner 
to exceptional numbers (e.g. beyond machine 
precision) . 

3. Formatted I/O still does not solve the 
general problem of number to string and string 
to number conversions. 

The University of Illinois PASCAL compiler has 
a rather elegant solution to this topic. This 
implementation of PASCAL allows the user to 'read' 
or 'write' numbers or strings to and from arrays 
as well as files. 

Sincerely vours, 



Robert E. Novak 



INDIANA UNIVERSITY 

Research Computing Center 

Wrulj^ B QQm^u^iij & ^nter 

BLOOMINGTON, INDIANA 4740! 



September 22, 1976 
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PASCAL User's Group 
c/o Andy Mickel 
University Computer Center 
227 Exp. Engr. 
University of Minnesota 
Minneapolis, Minnesota 55455 

Dear Andy: 

Since your visit to Indiana University last Spring and 
with some prodding from Al Towell, I v ve become "hooked" on 
PASCAL! V/ith my administrative responsibilities in the center 
I have not been able to spend the time on the language that I 
would like (I.e. I T m not an "expert" yet); nevertheless, it 
is clear to me that the language far exceeds (elegance, read- 
ability, flexibility, etc.) anything else that is generally 
available. I am gratified to see the formation of PUG (enclosed 
is a $4.00 check for membership); if ever users (without manu- 
facturers ' interference) have had an opportunity to do a great 
service to the computing community, this is it. ..we must not let 
the language get away from us by allowing local extensions to 
creep into widespread existence without a proper review proced- 
ure (Eg. a PUG Standards Committee. . .we have a "jewel" here that 
needs protection). I also support Hellinut Golde's belief that 
the widespread acceptance of PASCAL is dependent on the ability 
to mix Fortran and PASCAL main- and s ub -pro grams ; Fortran (an 
historical accident) can only be corrected if programmers are 
able to "grow" to PASCAL gradually. 

As my expertise in the language develops I hope to con- 
tribute to PUG T s primary roles... to maintain the integrity and 
promote the acceptance of PASCAL. 

Sincerely, 
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StepTf^n W. Young 
Director 



SWY/pce 



P.S. 



I know of at least two PASCAL users; hence, 
"PASCAL User's Group" should become "PASCAL 
Users' Group!" 
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DEPARTMENT OF COMPUTER SCIENCE 
THE UNIVERSITY 

MANCHESTER 

M13 9PL 



Telephone: 061-273 5466 

29th September 1976 



PROFESSOR OF COMPUTER SCIENCE 

T, KIL3URN, C.B.E.,M.A..Ph.O., 

D.Sc..F.I.E.E.,F,B.C.S..F.R.S. 

ICL PROFESSOR OF COMPUTER ENGINEERING 

O. 8. G. EDWARDS, M.Sc. Ph.D.. M.I.E.E. 

PROFESSOR OF COMPUTING SCIENCE 

F. H. SUMNER, Ph.D.. F.B.C.S. 

PROFESSOR OF COMPUTER PROGRAMMING 

D. MORRIS, Ph.D. 



Mr. Andy Mickel 

University Computer Center 

227 Experimental Engineering Building 

Minneapolis 

Minnesota 55455 

U.S.A. 



Dear Andy, 

Thanks for the letter and detailed information that you sent. In an 
attempt to get this to you by 1st October I have only included the 
following: , 

J. Documentation relating to Pascal at UMRCC 

2. Details of our CDC 7600 implementation 

3. A short note on our experiences with Pascal under NOS 
on the CYBER 72 

4. A copy of the updates to the compiler mentioned in item 3. 
Feel free to use, distribute or destroy! any of these mods 

5. Details of a possible bug in the Zurich compiler. Lack of time 
prevents me from finding the cause, so I will only send you the 
evidence this time. 

I would also like to advertise the fact that I wish to see formed within PUG 
a Pascal Standard's Group, which I am willing to organise unless a more 
suitable candidate volunteers. If I am not overtaken by events I will 
contribute a brief outline for Newsletter $1 of how the standards group 
might operate. 

Yours sincerely. 



DEPARTMENT OF MATHEMATICS 
CHRISTMAS-SAUCON HALL #1* 



LEHIGH UNIVERSITY 

BETHLEHEM. PENNSYLVANIA I8CH5 

October 9, I976 
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Tony Addyman 

P.S. This will be late - I've been ill. 



Mr. Andy Mickel 
PASCAL Users Group 
UCC: 227 Exp. Engr. 
University of Minnesota 
Minneapolis, MN 55^55 

Dear Andy: 

The first PUG Newsletter was really well done 
the good work. 



en 



keep up 



I was sorry to read that Dr. Waite initially declined to 
Join because of the dues cost. Since I suggested the membership 
rate (on the principle that "there ain't no free lunch") and I 
regard Dr. Waite as having potentially great positive influence 
on PASCAL development, I hereby contribute his dues. I hope Dr. 
Waite will use the Newsletter as the two-way communications 
channel it was meant to be. 

I enclose an article from the British Computer Society 
Bulletin. The article, entitled "Which Language?", shows that 
within the next five years PASCAL could become the language of 
choice for university computer science programs. 

I also enclose an article which addresses a mishmash of 
topics. In it are presented some frankly half-baked idea3. I 
hope the membership can cook them down (by stepwise refinement). 
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Richard J. Cichelli 
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University of Illinois at Urbana- Champaign 

COLLEGE OF COMMERCE AND BUSINESS ADMINISTRATION 
DEPARTMENT OF BUSINESS ADMINISTRATION • 350 COMMERCE BUILDING (WEST) • URBANA, ILLINOIS 61801 • (217.) 333-4241 

October 11, 1976 



Andy Hickel 

University of Minnesota 

University Computer Center 

227 Experimental Engineering Bldg. 

Minneapolis, Minn. 55455 

Dear Andy: 

I have some further comments on PASCAL, based on my experience as the local 
implementor of the Hamburg DEC-10 version. First, on the compiler itself. 
My comments, as published in the Newsletter (No. 5) were possibly a bit too 
harsh. They did not make it clear that my objections were to the interface 
between the compiler and the system, not to the reliability of the compiler 
or the quality of the code (aside from one bug in parameter passing - my 
blanket attack on procedure linkage seems to be more applicable to the older 
PASCAL compiler, rather than PASREL, the one we are now using). However the 
main thing I have to say is that I am unable to report on the usage of PASCAL. 
As far as I know there isn't any, except a few computer operators who use it 
to do homework that was supposed to be done on the Computer Science Depart- 
ment's PDP-11 PASCAL system. I thought you might find my analysis of this 
situation useful. 

Our lab is entirely a research organization. Much of our computer programming 
is "peculiar" in one way or another, and PASCAL turns out not to be very use- 
ful for it. First of all, we are often doing unusual input/output operations: 
controlling a robot, or doing random access work. PASCAL can hardly be blamed 
for not having the facilities to handle real-time device control. We have 
even had to modify the operating system slightly for that. But it does not 
support random access file manipulation, or for that matter any non-buffered 
kind of I/O. 



Andy Mickel 
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October 11, 1976 



Second, we do a considerable amount of work in artificial intelligence. PASCAL 
certainly has the ability to build complex data structures, but these abilities 
are rather low-level compared to LISP, or even SAIL. To do what we do with 
LISP in PASCAL, one would apparently have to write a memory-management system, 
either garbage-collecting or reference counting, and then build up a collection 
of basic procedures to manipulate the structures. I.e., one would nearly have 
to rewrite LISP in PASCAL. More about this below, under runtime memory 
management « 

Finally, we do a good bit of what might be called "system hacking." This 
includes writing system programs such as a mail system, various programs for 
displaying information about system status and parameters, for analyzing dumps 
of moniter crashes, editors, etc. All of these programs require us to make 
many obscure monitor calls and to transform data between the form used iri~ 
monitor calls and usable external forms. PASCAL provides no facilities for 
doing monitor calls (since these are by definition machine - dependent) , nor 
does it supply the large library of conversion procedures that SAIL, for 
example, does (SIXBIT to ASCII, etc.). 

More generally, the lack of string processing facilities makes many tasks 
rather Inconvenient. This really falls into the same category as my complaint 
that PASCAL is not LISP, since we are again talking about a lack of run-time 
memory, management. String processing appears to require this as much as list 
processing. By run- time memory management I mean the ability to do NEW 
repeatedly, without eventually running out of space. This seems to require 
garbage collection, reference counts, or some such scheme, as well as an 
ability to get more memory from the operating system when it is needed. I 
realize that this is a controversial issue. If PASCAL is intended solely as 
an implementation language, it should not supply a built-in memory-management 
scheme since that is one thing that an implementor will want to design for him- 
self. But I believe it is unreasonable to expect applications programmers to 
include a garbage collector and/or memory allocator in every program. I find 
it hard to believe that any serious use can be made of NEW without some memory 
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Andy Mickel 



October 11, 1976 



management. Indeed the DEC-10 PASCAL compiler uses extensions to PASCAL to 
keep its symbol table within bounds. Possibly built-in garbage collection 
should be available only when specifically requested. Then implementors who 
wish to design their own memory management would be free to do so. 

Also, no attempt seems to have been made to facilitate decoding anything other 
than numerical input items. I sat down to write a program that would read a 
program name from the terminal and then run it. I knew that I would have to 
do the running by a call to an assembly-language subroutine. But when writing 
the filename scanner began to look like writing the syntax analyzer for a 
small compiler, I gave up and used SAIL. In fact, this was my last attempt 
to use PASCAL. (Filenames on the DEC-10 are not trivial: A full-blown one 
might be DSKBjPGM.EXE [5, 731, SAIL, SRC] . Almost any part can be left out, and 
gets a default value. Also, the bracketed item can come first). 

I think the real issue is what kinds of problems PASCAL is intended to attack. 
It is unreasonable to expect any general-purpose language to have the peculiar 
capabilities of LISP. That one could write a LISP interpreter in PASCAL is 
possibly all that should be asked. The inability to handle messy I/O and 
"system hacks" seems more serious , though. If we give up on that it seems to 
limit PASCAL to compiler writing and a replacement for FORTRAN. (Its short- 
comings as a replacement for COBOL have been noted elsewhere.) The best 
language for such things on the DEC-10 is SAIL, a Stanford University 
extended ALGOL. It makes no pretense at machine- independence. There is a 
syntax for doing monitor calls directly. Any I/O mode available in the 
monitor may be explicitly specified (and is handled automatically, so that 
buffered and unbuffered I/O can be done with the same higher-level language 
constructs). A huge library of special purpose procedures is provided, 
including conversion procedures that allow one to make sense of data in 
funny monitor formats. If all else fails, one may insert sections of 
assembly language in the middle of a SAIL program. Accumulators are freed 
for your use, and constructs are defined to let you refer to the address of 
array elements, record elements, etc. in higher-level terms. SAIL also has 
several data types that depend upon runtime memory-management: e.g., strings, 
lists, and records. (I believe these three classes are separately garbage 
collected.) 



SAIL is certainly not the ideal programming language, especially when judged 
by the "structured programming" and machine-independence ideals that guided 
the design of PASCAL. But I find it hard to imagine myself adopting a language 
for day-to-day use that did not have most of its features: the ability to 
use all of the facilities available in the operating system, run-time 
memory-management, and a good library of special-purpose procedures. Unless 
PASCAL can find a way to incorporate some of this in a reasonably structured 
way, I think it will not get beyond introductory computer science courses. 
Unfortunately, PL/l comes very close to meeting my goals (especially when 
used with OS/360). I fear I may find myself teaching students PL/I when 
I had hoped to use PASCAL. 

Sincerely yours, 
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Charles L. Hedrick 

Assistant Professor of Business- 

Administration 



CLH/jh 



GO 
f> 

3> 



m 

7XD 



en 



CD 



CD 






Xerox Corporation 
Palo Atto Research Center 
3333 Coyote Hill Road 
Palo Alto, California 94304 
(415) 494-4000 
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WEST TEXAS STATE UNIVERSITY 
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October 21, 1976 



Mr. Andrew B. Micke! 
Editor, Pascal Newsletter 
Computer Center 
University of Minnesota 
Minneapolis, Minn. 55455 



Dear Andy, 



Upon reading the last issue of the Pascal Newsletter I was surprised to find that you do 
not distinguish between private letters and letters to the Editor. I strongly disagree with 
your elimination of this distintion, and fear that some of the writers of the published 
letters may resent your zeal for transparency. 

I suggest that letters for publication must explicitly be addressed to the Editor of the 
Pascal Newsletter (as shown above), and that no other letters will be published. 

Yours sincerely, 

IJaJcIciw y(ihi tiL 

Prof. N. Wirth 



Mr. Andy Michel 
227 Experimental Eng. Bldg. 
University of Minnesota 
Minneapolis, MN 55455 

Andy: 

I have just recently finished reading from cover to cover the 
Pascal Newsletter Number 5. You guys deserve a big commenda- 
tion from all advocates of progress in programming languages 
especially advocates of PASCAL and its future development. 
With such a common forum as the Newsletter, perhaps we can 
interact in such a way as to encourage if not force, a "stan- 
darcl " series of improvements to PASCAL. 

In one of the letters (T have searched several times for the 
specific one) there was mention of an implementation of Brinch 
Hansen's concurrent PASCAL. Could you please give me informa- 
tion concerning the availability of concurrent PASCAL for the 
DEC System - 10. That appears to me to be a desirable way to 
go with the operating systems course. 

Keep up the good work. I will support you in spirit and con- 
tinue to send in my monetary support, for the Newsletter. 

Sincerely 
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H. P. "Duke" Haiduk 
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The University of Tasmania 

Postal Address: Box 252C, G.P.O., Hobart, Tasmania, Australia 7001 
Telephone: 23 0561. Cables 'Tasuni' Telex: 58150 UNTAS 
INFORMATION SCIENCE DEPARTMENT. 



IN REPLY PLEASE QUOTE: 

FILE NO 

IF TELEPHONING OR CALLING 
ASK FOR 



Pascal User's Group, 

C/- Andy Mickel , 

University Computer Center, 227 Exp. Engr. 

University of Minnesota, 

MINNEAPOLIS, MN. 55^55 



22nd October, 1976. 
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Department of MaHiematics 

The University, Southampton , J>09 5NH. 



Telex 47661 
Tel 0703 559122 Ext 2387 



The University of Southampton 



COMPUTER STUDIES GROUP 



October 4, 1976. 
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Oear Mr. Mickel , 



PASCAL NEWSLETTER 



Judy Mull ins, of the University of Southampton ICL 2900 project, has 
i believe been sending you copies of the correspondence we are generating between 
.Tasmania and Southampton on the common problems of implementing PASCAL on highly 
structured computers (B6700 and ICL2900) instead of the more usual monolithic 
machines. I enclose therefore my reply to the last letter she sent you, in case 
you want to include it in the Newsletter. It contains, I think, discussions 
of several important issues. 

Some time later I must write a view for the Newsletter specifically 
on PASCAL development, for it is clearly going off the rails (clear to me anyway). 
A great pity, and something should be done to remedy the residual problems in 
definition and to encourage greater interchange of programs and program portability. 
1 shudder at all those PDP11 and IBM 370 implementations.' 

I enclose also a release on the status of the B6700 PASCAL 

compiler, which I ask you to print. It should clarify the situation for any 

interested B6700 users on a machine which is noted for the rarity of any new 
compilers. 



Yours sincerely, 



Ends. 



A.H.J. SALE, 
Professor of Information Science. 



Dear Professor Sale, 

Thank you for your long and most informative letter. It has raised 
two. points which are of interest to both our Universities as well as, I believe, 
the Pascal community in general. These are 



and 



What brand of Pascal should be implemented? 
How is it implemented on high-level machines? 



we have had long discussions on these questions, both previously, and in the 
light of your letter. Here follow our views. 

What? We believe, for better or for worse, in Standard Pascal, as laid down 
in Jensen and Wirth. The 1900 compiler which we are bootstrapping is a full 
implementation of the Standard with one exception: the Pascal 1 1/0 routines 
are kept (e.g. write (eo£) , while not (ch=eo£) do read (ch) etc). Considering 
the mess the Zurich compilers got into when Ainmann tried to rationlize the 
readJcn procedure for integers, we consider this a wise choice. However, Jim 
Welsh is proposing to support read£n, write£n in tandem with the other set, to 
ease portability problems. To be realistic one must accept that there is no 
such thing as a fully portable program, but if the changes are few and well 
understood then an intelligent programmer will have a small, albeit irritating, 
task to bring an alien program up on another machine. The syntactic changes in 
your implementation are good ones except for the % comment which reminds me 
too much of assembler, and the ELSE case label (more of that anon). But if you 
allow all these goodies and students get to know of them, it merely widens the 
communication gap both between the students and the excellent text books that 
are beginning to appear on Pascal, and the students' programs and other machines. 
Burroughs installations have for many years fed the Algol 60 communication gap, 
and gaily ignored its consequences. Certainly, B 5700 Xalgol programs are more 
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readable and better in m.tny respects than their "equivalents on conventional 
machines. Tot h^ve their ideas been copied? Experience has shown that 
people will slick to a standard unless it is quite intolerable. Fortran is 
just inside th:-. tolerable, BASIC (as defined at Dartmouth in 1971) is not. 
Extensions boomed with the result that the Standardisation Committee cannot 
hope to produce a useful document now. Pascal must have a more promising 
future. 
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Firstly, we believe that. Pascal is well within 
parse language which gives it its main advantage - tight 

It is veil-defined, well-documented and supported by 
ily available journals. It also represents a great 

data structures and readable self-documenting 
hall implement Pascal as in the Report, and that alone 
, there are holes that cannot be ignored and two of 
e I/O and diagnostic aids. We are taking the line that 
oach as little as possible on the Pascal source. What 

needed for files on the 2970 will only be considered 
all keep you informed. If you could send me full 
face, it will be around at the vital moment and we can 
an be Biade to conform at all. 
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Glasgow have implemented a 
, profiles and tracing on the 1900 
2900 as soon as our compiler is ready, 
system is simple and induces minimal 
itic procedures write information to 
t mortem program (written in Pascal) 
its report. All very clinical! I 
In conjunction with David Watt and 
ser interface from the horrible 
(proposals attached). Global options 
nt (be it CONST, PROGRAM OR PROCEDURE) 



OPTION LIST « FALSE; 

RETROTRACE = 500; 

with suitable defaults, local options come in as comments e.g. 

(*$ LISTOFF, TRACEOFF *) 

One further hole is that of separate and mixed language compilation. 
There is a strong feeling to keep to the Burroughs idea of all input in Source. 
Could you send me details of the B6700 INCLUDE options as we shall no doubt have 
to write our own software to do this? By the way, what do you think the 
meaning and implications of assigning one file to another are? If one could do 
this in a sensible way, then each IMCLUDEed file will be activated in the 
compiler by a simple input := newname ! The decision for mixed language 
programming is a sticky one, but necessary because of the tremendous library 
resources available in Fortran. We hope to be able to provide this and the 
INCLUDE option. For once, the 2900 design is helpful: the compiler output format 
proposed for March 1977 and thereafter, Object Module Format, can be input to 
the collector or the loader. 
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I hope you don't mind if I send a copy of this letter to Andy Mickel for the 
P.U.G. newsletter as I had been meaning to write to him on the same topic. 
On the phone about distributing newsletters, he reiterated his concern about 
the health of Pascal and the extent to which, it is diversifying. No one is 
quite sure wh;-t to do, except worry, but I agree that a committee is not the 
answer . 

I haven't broached the second question (i.e. How?) but that will have to 
wait for another letter. Before I close, two quick comments. 

ELSE case label: I had the opportunity to discuss this with Wirth and his 
objection is a very valid one i.e. the programmer will put the ELSE there to 
catch values which he expects, but wants to treat in such-and-such a way. What 
will happen is that it will also catch those inevitable values that "can't 
possibly occur" and the program will produce wrong results, when it should have 
halted in error. 

SYNTACTIC SUGAR : Your syntactic options (TO instead of.., OF instead of:) 
become almost justifiable if you provide a macro processor, written in Standard 
Pascal which will convert any B6700 program to the Standard. This will put 
some rein on the extent of the changes, and can be given to any serious 
programmer who leaves the B6700. 

Yours sincerely, 
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Judy Mull ins . 



Professor A.K.J. Sale, 

Information Science Department, 

University of Tasmania, 

Box 252C, G.P.O., 

Hobart, 

TASMANIA, 

Australia 7001. 



cc. Andy Mickel 



Enc. diagnostic system document 
OPTION syntax proposal. 
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The University of Tasmania 

Postal Address; Box 252C, G.P.O., Hobart, Tasmania, Australia 7001 
Telephone: 23 0551. Cables 'Tasuni' Telex: 58150 UNTAS 
INFORMATION SCIENCE DEPARTMENT. 



22nd October, 1976. 



Miss J. Mul 1 ins, 
Department of Mathematics, 
The University of Southampton, 
SOUTHAMPTON , S09 5NH 
UNITED KINGDOM. 



Dear Miss Mul 1 ins, 



Thank you for your letter. Let me try to answer your specific 
points; some of which 1 agree with, and some of which horrify me. I have drafted 
part of this letter as a person-person communication, and part as open comments 
on aspects of the PASCAL development cycle. 

Standards . - 

Of course I agree that standard PASCAL must be adhered to, but not to the absolute 
exclusion of all deviation. A few features of PASCAL ought not to have been 
standardized ( incontrovert ibly in my opinion), and if absolute adherence is demanded 
I fear for the future fate of the language. Consider that programmers do not in 
general change languages unless they perceive advantages in several areas. A 
delightful language embedded in a lousy implementation, or with poor facilities, 
may not displace a poor language which has evolved into a good support situation. 
PASCAL vs FORTRAN for example 

I cannot agree with your comments on the likliness of adherence to standards. 
Standards are maintained as limits by programmers for reasons which are quite 
independent of the tolerab? 1 ? ty or otherwise of the language . Indeed, 1 think 
that PASCAL is quite as much under pressure from burgeoning differences as was 
BASIC, and for very similar reasons. It should not have escaped your notice that 
adherence to the limits of the FORTRAN standard is not the common practice of 
FORTRAN programmers, not yet of the supplier's compiler-writers. Where it is 
adhered to, it arises out of the need to write portable software. This is the 
prime determinant of adherence to standards by programmers ; a certification process 
is of some effect with compiler-writers. 

Frankly, I think that insufficient thought has been given to ensuring a healthy 
future development of PASCAL, just as insufficient thought was given to the problems 
of its portability. The very sparseness of the compilers are an encouragement to 
diversity, with all the effects one can witness in the PDP-11 and IBM 370 
implementations, not the reverse. 1 have given a lot of thought to the ecology of 
languages, and perhaps I can best give notice of a diatribe on suitable protection 
of PASCAL'S niche. 



Ch aracter codes 

Ouch.' If you are honest about standards you should realize that inventing any new 
character set (even if It be ASCII offset by 6*0 is just plain stupid. No-one 
outside Europe would contemplate it, even if ASCII and EBCDIC are not all one could 
wish. Neither Is your alternative, of course. If I were involved in your project 
I'd scribble with a huge red pen through that proposal J and tell you 
to go and live with the standards. Fortunately, the axiomatic definition of PASCAL 
cha_r admits that the alphabet ics might not form a compact set (as they do not in 
EBCDIC), nor an order between space/digits/lowercase/uppercase. Why is it so 
important to you, anyway? 

I hope this will make you not quite so pleased about PICS. The set constructs you 
quote should be possible given any large enough set^ implementation, but if one has 
to be aware of some structure of the language's character set, I see no reason 
why you need to have a new one of your own. Try 

. IF CH IN ["A" TO "2", "0" TO "9 U , "a" TO ,l z"3 THEN 

IF CH IN [-"A" TO "I", "J" TO "R", "S" TO "Z"j. THEN 

Frankly, ! cannot either see why you think all ASCI Ms low 6*t control codes and 
lower-case are so unimportant. Perhaps you are not thinking of an interactive 
environment; just of a number-crunch set of users with batch? 

Did you realize too that if PICS is available and the default, you will inevitably 
have programmers using CHR and 0RD writing programs that are non-portable for 
quite mysterious reasons? 

If you can convince me that you can supply a program (written in Pascal of course) 
that will accept Pascal program source text written to use PICS, and wi 1 1 produce 
equivalent Pascal program source text that uses EBCDIC, 1 might almost begin to 
think the innovation just acceptable.' 

B67Q0 % comment 

Yet, it is reminescent of assembler isnt it? But not all assembly language 
features (nor yet FORTRAN) are bad. Although PASCAL'S comment facility is streets 
ahead of Algol's, BASIC'S or COBOL's, it still has a few defects, such as a 
propensity for 'swallowing text without trace. This is a minor addition (experience 
shows that this sort of comment is preferred by programmers than having to close 
one off) to keep B6700 compatibility, and to entice B6700 programmers to transfer. 
A few lollies help now and then will do wonders. 

1 have in mind too prime requirements for extensions: an extension should fall 
into one of two classes: it can be removed by a simple context-free program to 
produce a standard-compatible version, or the facility provided is quite unavailable 
in the standard. This falls into the first class. 



ELSE in CASE 



I have heard the argument you attribute to Wirth before, but 1 cannot give it 
much force. In fact, PASCAL leaves undefined the action of a CASE where the 
expression evaluates to a value not matched by a case label. Consider the 
situation (I nearly wrote "case") where 

(i) the value is in-range of the type, but not represented, and 

(ii) the value is out-of-range of the type. 
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It is arguable that in the first case the effect should be "do-nothing" on the 
analogy of IF-THEN; or it should be a run-time error on special arguments. I 
personally incline to the second (as Wirth), but the first is far from Indefensible. 
Only in the second case should a run-time error always be caused; and this may be 
for reasons quite independent of the structure of the CASE, but simply because of the 
type involved. There are a few nasty spots with semi- inf in i te types (integer)... 

I remain unrepentant: ELSE in CASE is a feature which mirrors the way programmers 
think and offers ways of epxress i ng things that are unbearably cumbersome without 
it (try a CASE on char in a lexical analyser), though I will concede that some 
poor programmers can misuse it. But this is true of other features of PASCAL, for 
example in the REPEAT where the relation is expressed as an "escape" condition 
instead of a "cont inue-looping" condition, encouraging widening the liklihood 
that infinite loops are created. . ■ 

As a further argument I wi 11 ask you to put yourself In the position of a compiler- 
writer writing a compiler which you know will be used on the other side of the 
world from you. You use hundreds of CASEs. All of them should be proof against 
flaws and bad input. Your end-users will curse you (and not sotto voce) every 
time the compiler crashes because of an out-of-range CASE. Are you then willing to 
forego ELSE in favour of laborious and error-prone lists of alternatives not 
expected? Robustness is as much a virtue as correct behaviour with expected input 

Mixed-language 

You put your finger on a severe and very important spot. See my longer comments. 
The B6700 problems revolve around the complex structure of the code-file, and the 
complex actions taken by the BINDER to reorganize the outer-block stack for OWN 
objects, and the segment dictionary for VALUE objects. Tie this up with stack 
cleanup activities, files, and binding external objects (including files) by name 
into externally compiled procedures, and checking parameter compatibility at bind- 
time, and you may realize that the complexity of a codefile with B1ND1NF0 is an 
order of magnitude larger than an executable codefile. 



Files 



Yuk! I detest your assignment idea of files. See expanded comments. Distinguish 
between compile-time actions (an INCLUDE) and run-time actions (an :=) ; and keep 
the := for total change of the entity involved. I suspect in fact that files might 
have been better out of the VAR part, and into an environment specification, which 
would have been more accurate. Who knows; it's too late? 



Compi ler opt ions 

Unless you are absolutely stuck on every detail of the CDC PASCAL implementation, 
you will not implement compiler options in the same way. The mechanism for specifi- 
cation is too terse, unimaginative, and not self-explanatory. Judging from previous 
remarks emanating from Southampton, there is probably no fear on that score! 
May I suggest that the B6700 style is quite good, whether it begins with a $ on a 
newline, or is enclosed within a PASCAL comment. Look it up in the manuals (Algol 
say), but breifly one can SET, RESET or POP an option name, each being regarded as 
on a bit-stack (^8-bits deep). SET and RESET push the stack down and insert the 
new value. Some options can have numeric values, in which case SET/RESET/POP are 
not relevant, and a few are special (INCLUDE). User-defined options are also 
allowable, allowing the user to set up source text which is parameterizable at 
compile-time (as assembly-code programs could often do). We use user-options to 
control the insertion of checking-code in the semantic code-generation routines 
(compiler debugging) and probably for B67O0/B770O minor differences. 

Examples which might be self-explanatory (unlike T+, etc.): 

SET LI ST, TABLE, CODE, LINE INFO, EXTRACHECK 

RESET LISTINCL J 

POPLISTINCL user-option name, freely chosen 

SET OMIT=EXTRACHECK 

ERR0RLIMIT=100, HEAP=2000 

The B6700 native style is 

$SET LIST, TABLE, CODE, LINEINFO 
while a PASCAL adaption might be 

{SET LIST, TABLE, CODE, LINEINFO) 

SETS 

Why do you not make a first implementation of sets which stores them as a packed 
array of bits , and therefore pointed to by a descriptor? Since there are no set- 
constants as such (the set-constructor is funny), you can get away with it, and 
operations on sets can be done either by in-line code, or by intrinsic procedure 
calls. Bit-testing (v j_n s) can be implemented by using the low 5 bits (=32 bits 
of your word) as a bi t-w? thin-word index, and the remnant of the set-element as a 
word-wi thi n-array index. This is how we shall implement any-size sets, though we 
move from one-word sets to this. You might choose to implement any-size and 
introduce an optimization for small sets later..,. It might get you out of that 
silly character problem. 
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Diagnostics 

No real comment; all seem good ideas, though my Burroughs experience leads me 



to suspect that 1 would spend more time ..-,....,.-, _ r _. a _, 

else. I have in mind also allowing a facility so that interactive users can 
browse through the saved state making enquiries of variables, etc. Dumps of an 
sort are sledgehammers, where screwdr* 
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BOUNDS CHECKING 

The Welsh's technique of compile-time bounds checking was going to be built into 
our compiler, but has not been on the first attempt. Primarily this is because 
we have been focussing on our main problem: the B6700 and its system, and not 
so much on nice features of the compiler. I think I have a long list of run-time 
and compile-time improvements which we shall consider when the compiler reaches 
its second stable point (with a comprehensive file and i/o facility). 

Incidentally, I am not at all sure that read(ch) dominates our compiler's speed; 
intuitively it seems unlikely given the very efficient lexical analyser. My 
estimate at the moment is that, the speed is mainly limited by the symbol table, 
and by the code generators. 
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B67GOs 



It does not surprize me to hear that Warwick University do not have compiler 
expertise. It is very rare in B6700 installations; no-one writes compilers for 
86700s, or so it seems to us. All sorts of people fudge the existing ones, but 
that is a quite different activity from creating a complete system. Tell me of 
your impressions of" B6700 expertise available close to you. This is one of the 
reasons we have been accumulating information in this area, so that we can become 
experts and hopefully contribute to the future of structured computers. 



Trans Union 
Systems Corporation 



111 West Jackson Boulevard 
Chicago, Illinois 60604 
312/431 3330 
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Arrays, and off-stack storage 

I suppose you'd noted that our compiler does not store any multi-word object 
on-stack (apart from the double-word items such as double-precision and possibly 
complex variables). Instead there is a descriptor (one-word) for each multi-word 
object, which describes a linear piece of core containing the object [array of 
integer, array of record, array of array, record, record of array, etc.). If 
large enough (say more than 1 02 A words) the linear store will be segmented into 
the B67OO 256-word pages. 
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Pointers 
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Since pointers point only to things in the heap, and since the heap descriptor 
location is known to the compiler, we store pointers as one-word integers (with 
zero used as the nil value at present). Since a single vector on the B67OO is 
limited by the software to about 150k words, we could pack it into less (say 20 
bits) if we need to. I'll probably change the nil value to some out-of-bounds 
index so that the hardware checks will trap it. 



October 29, 1976 

Mr. Andy Mickel 
University Computer Center 
227 Exp. Engr. 
University of Minnesota 
Minneapolis, MN 55455 

Dear Mr. Mickel: 

Looking over the September issue of the PASCAL news- 
letter, I quickly concluded that the Tokyo compiler is the only 
one likely to serve our needs. Since we contemplate using 
PASCAL in commercial applications we need a reasonably 
reliable and efficient implementation, and the only other one 
that meets those criteria is the Manitoba compiler; but it 
supports 1/0 only on a card reader and a printer, which (for 
us) is absurd. But the most recent published information on 
the Tokyo compiler is dated from the middle of May. Has 
there been any progress since then? We're strongly interested 
in getting a copy of it as soon as it is available to run 
under IBM's OS/370 control program. 

Very truly yours, 
Jonathan Sachs 
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Speed and Space 

It may interest you to see those sample jobs I sent you and note that PASCAL 
compiles the twiddly job at about 10% - 20% slower than ALGOL or FORTRAN, but 
executes in about 5 the code space (*»k instead of 8k average) and about 70% of 
the data space - (5k) . Space is a global property, so the small size is very welcome 
Speed is a local property of programs, and perhaps some tuning will quite reverse 
the situation, though perhaps not by much. 



I await 'your next letter with interest; \ too have forwarded a copy to the 
Newsletter. 

Yours sincerely, 



JS/U& 



A.H.J. SALE, 
Professor of Information Science. 
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Timothy M. Donham" 
D605/I630 6. 6th St. 
Minneapolis, tki 55^5^ 

11-04-76 
COMMENTS ON SEV&iAL ITEMS: 

Dynamic Array Parameters'. . .Jac obi's proposal is very welcome; it will 
fill an area in Pascal that many users have perceived as wanting in 
comparison to other languages. Further, the structure seems to fit 
well into the present Pascal syntax and does not appear too difficult 
to implement. However, one area of the proposal seems debatable to 
me — the standard functions 'low 1 and 'high'. It seems to me that one 
of the reasons for the success of Pascal is the close resemblence of 
many of it's features to those of other languages such as ALdOL and 
FOitTitAN. Biis makes the task of programmers who already know those 
languages and are attempting to learn Pascal much easier. I strongly 
agree with C. A. H. iioare (in his article "Hints for Programming 
Language Design") that a main task for the language designer is con- 
sistency and consolidation — both within the language, and, if possi- 
ble, with other languages. For this reason I would suggest that these 
standard.. functions be given the names 'lowbound' and 'highbound' 
instead of 'low' and 'high'. This would be more consistent with the 
names used for the similar functions in AKrOL and PL/l. I do not 
think that the minor disadvantage of slightly longer names is sig- 
nificant; especially in consideration of the way in which the names 
'lowbound* 'arid 'highbound' more clearly express the meaning of these 
standard functions. 

Standardization. ,. It is becoming clear that Pascal is in need of an 

"official" standard, formally published by some group sur».h as ANSI. 
The language is presently plagued by a host of inconsistent and con- 
tradictory additions, extensions, and modifications. If this trend 



is allowed to continue, rascal >/ill soon become no more portable thart 
BASIC. There w«ro several communis on this in Newsletter ,-5. 1 
would like to add my voice to those who seem to he calling for a 
Pascal Standards Committee to define a formal "standard". I'm 
somewhat nervous about a committee — -'especially the; tendancy thoy 
seem to have to compromise rather than choose the best; but I don't 
know of any other acceptable way to go. Hopefully the committee structure 
will be similar to that of SIMULA, where the committee members are 
themselves implementors (thus insuring that the implementations are 
standard and the standards are implementable) ; and that there uill bo 
a lot of communication between the committee and the users. I would 
be very willing to assist such a committee in any way that I could, 
and I hope that something is organized soon, before pascal becomes 
more a collection of similar dialects than a single standard, portable 
language. 
Implementations. ..Does anyone have any information on a pascal compiler 
for the IBM System 3? (If there are none available, this would seem 
to be a good project for some computer science student, since this 
machine is widely distributed.) Also, does anyone know of a 
compiler for the Control Data 3200? 
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IMPLEMENTATION NOTES 



The IMPLEMENTATION NOTES section of the newsletter is organized, as follows: 

1) A checklist to consider when sending us information about distributed 
versions of S + andard Pascal. 

2) Pascal -P, a "portable" compiler of Pascal for a hypothe+ical "stack 
machine". It comes on tape as a kit and may be used to bootstrap 
compilers onto real computer systems. 

3) Other portable compilers: Pascal Trunk compiler, Pascal -J, Pascal-S, 
and Concurrent Pascal . 

4) Implementation independant software writing tools. 

5) Compilers and software writing tools for specific computers sorted by 
computer system. 

Our policy is to pr int only new information. If you do not find what you are 

looking for in Newsletter #6, check #5. 



As Newsletter #6 goes to press, we still do not have enough implementation 
and distribution information. However, thanks to Timothy Bonham, we sent 
requests for information to over 80 known implementors late in October. The 
responses we have received since then have been very gratifying. We thank all 
of you who have taken the time to respond, the replies have been a big boost for 
this section of the newsletter. 

Again we must stress that we need more information. The PUG Newsletter is 
the focal point for communications dealing with Pascal; implementors and 
distributors must keep us informed. We encourage users to share their 
experiences by sending qualitative and quantitative descriptions of particular 
implentations. Please realize that individual requests for information are a 
great drain on our resources. 

Those sending information are encouraged to consider the checklist, and if 
possible, to supply a short order form (both "camera ready"). To further the 
spread of Pascal, and avoid duplication of effort, this section should be kept 
complete and up to date. -John. 



(SOURCE INFORMATION, PROPOSALS FOR EXTENSIONS TO STANDARD PASCAL, 
BUG REPORTS, PROGRAM WRITING TOOLS, ETC.) 
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CHECKLIST - CHECKLIST - CHECKLIST - CHECKLIST - CHECKLIST - CHECKLIST 



1. Names, addresses, and phone numbers of implementors and 
distributors. 

2. Machine(s) (manufacturer, model/series). 

3. Operating system(s), minimal hardware configuration, etc. 

4. Method of distribution (cost, magnetic tape formats, etc.). 

5. Documentation available (machine retrievable, in form of a 
supplement to the book Pascal User Manual and Report). 

6. Maintenance policy (for how long, future development plans, 
accept bug reports). 

7. Fully implements Standard Pascal? (why not?, what's 
different?) 

8. Compiler or interpreter? (written in what language, length in 
source lines, compiler or interpreter size in words or bytes, 
compilation speed in characters per second, 
compilation/execution speed compared to other language 
processors (e.g. FORTRAN)) 

9. Reliability of compiler or interpreter (poor, moderate, good, 
excellent). 

10. Method of development (from Pascal-P, hand coded from 
scratch, bootstrapped, cross-compiled, etc.; effort to 
implement in man months, experience of implementors). 



CHECKLIST - CHECKLIST - CHECKLIST - CHECKLIST - CHECKLIST - CHECKLIST 
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PASCAL-P 

It seems that Pascal-P has been stabilized/frozen, in a letter of 
14 Sep 76 to George Richmond, Niklaus Wlrth stated: "As for Pascal-P, where 
we have done a major revision this pas+ spring, I cling to the hope that we 
can leave it at that, merely continuing the handling of new orders." 

To order Pascal-P, use the updated form on the following pages (* we 
apologize for the disjointness of the two parts of the form *). See 
Newsletter #5 for more complete information on Pascal-P, in particular for 
explanations of the installation parameters and magnetic tape format. 



If you are in Europe, Asia, or Africa, order from: 



Ch. Jacobi 

Institut fur Informatik 

E.T.H.-Zentrum 

CH-8092 Zurich 

Switzerland 

(phone: 01/32 62 11) 



If you are in North or South America, order from: 



Prices are printed on the order form, 
and include the cost of a mini-tape. 



George H. Richmond 

Computing Center: 3645 Marine St. 

University of Colorado 

Boulder, CO 80309 

U.S.A. 

(phone: (303) 492-8131) 



$50 for P3 and P4 tape and document. 

add $10 if Colorado supplies the tape. 

add $30 if the version is to be pre- 
conf igured to your machine 
(necessary if you do not have 
access to a working compiler). 

add $10 for a nine-track tape. 

add postage if not pre-paid (if you wish 
to be bil led). 

(* price information for options B 
and C is unavai lable. *) 



If you are in Australia, New Zealand, or Oceania (^Antarctica too?*): 



Carrol I Morgan 

Basser Department of Computer Science 

University of Sydney 

Sydney, N.S.W. 2006 

Austral ia 



$A30 for P3 and P4 tape (option A). 

(* price information for options B 
and C is unavai I able. *) 



IMPLEMENTATION NOTES 



Order form for the revised Pascal P system. 



Please provide us with your revised Pascal P system according to 
the specifications on the this form. 



Address for delivery of the system 
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The characteristics of our installation are 
Machine type 
Operating system 



Installation parameters (to be filled for case f A f below) 



intsize 

realsize 

charsize 

boolsize 

ptrsize 

setsize 

stackelsize 

strglgth 

intbits 

sethigh 

ordcaxchar 



intal 

realal 

charal 

boolal 

ptral 

setal 

stackal 



set low 

ordminchar 
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(SOURCE INFORMATION, PROPOSALS FOR EXTENSIONS TO STANDARD PASCAL, 
BUG REPORTS, PROGRAM WRITING TOOLS, ETC.) 



CD 






V.e order 



Basajf mMm jj^ j wLasm 



UNIVERSITY OF WISCONSIN- EAU CLAIRE EAU CLAIRE WISCONSIN 54701 



D 



□ 



- Pascal P^ compiler (in Pascal). 
*- Pascal P 1 ! compiler (in'PU code). 

- An assembler interpreter of P4 code (in Pascal, for 
documentation purposes, all alignment and size 
constants set to 1). 

- Pascal P compiler implementation notes with update 
list. 

- Pascal ?3 compiler (in Pascal). 

With line numbers, to indicate where it differs 
from Pascal P2. (All installation parameters set 
to a standard value.) 
Charge SFr 160.- 



(For users who have access to a CDC 6000 computer and 
want to experiment with the compiler) 

- Pascal P4 compiler with some changes, so that it is 
accepted by the Pascal 6000 compiler (in Pascal). (All 
installation parameters set to a standard value.) 

- An assembler interpreter (in Pascal, as in package 
•A' ). 

- Pascal P compiler implementation notes with update 
list. 

Charge SFr 80.- 



C - Update list to 'PASCAL-? compiler implementation notes', 
Charge Sfr 5.- ' 



Date 



Signature 
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25 August 1976 



PASCAL- P Progress Report 



Our interpretive PASCAL-P system has been running since 
November 1975. This summer the portable compiler was 
rewritten in Burroughs B570.0 compatible ALGOL, This new 
version of the compiler generates P-code which is sub- 
sequently "executed" by our P-code assembler/interpreter. 
Compile times have improved by a factor of 16 as com- 
pared to the interpretive system. I expect a further 
improvement of two to four will be achieved by rewrit- 
ing the procedures INSYMBOL and NEXTCH. 

Using the (slightly modified) PASCAL source code supplied 
with the PASCAL-P implementation kit, this new compiler 
has successfully compiled both the PASCAL-P compiler and 
the P-code assembler/interpreter. The source code for 
the PASCAL-P compiler contains several records ( lines in 
PASCAL terminology) longer than 80 characters. These 
had to be rewritten/shortened to make them acceptable 
to our new compiler. (We expect input to come from cards 
or a teletype.) Also, one or two long string constants 
had to be broken in two to satisfy the STRGLGTH restric- 
tion of our system. 

The source code for the P-code assembler/interpreter was 
a bit more troublesome since it is written in standard 
PASCAL rather than PASCAL-P. The problem areas were: 
too many long constants in procedure INIT; the standard 
types TEXT and ALFA; the standard procedures RESET, 
REWRITE, and PACK; an argument of type BOOLEAN in a 
WRITE invokation; an octal (that's right, folks!) format 
specification in a WRITE invokation; an actual parameter 
that was a string constant passed to a procedure expect- 
ing a PACKED array of type CHAR; the attempt to refer- 
ence the procedure PUSH -in procedure EX3 (PUSH is local 
to procedure EX0) ; string constants too long for our 
system; standard I/O procedures without file parameters; 
semicolons preceding the final END in case statements 
(surprise!); and a function (BASE) of type subrange. 
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The University of Wisconsin-Eau Claire is an Equal Opportunity employer and actively seeks applications from all qualified 
persons, whatever their sex, race, color, religion, national origin, or age. 
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Having completed the rewrite of the compiler, the next 
step was obvious -- modify it! 

The error codes emitted by our new compiler are different 
from those emitted by the Zurich compiler. The compiler 
tests for over 250 different syntax errors and each of 
these errors is now associated with a unique error code. 
This allows the corresponding error messages to be more 
explicit and, hence, useful to the novice users of our 
svs tern. 
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A future report will outline some of the ways in which 
our PASCAL system is being used in support of our Com- 
puter Science program here at the University of Wis- 
consin - Eau Claire. 



PASCAL TRUNK COMPILER (no new information, see Newsletter #5) 



PASCAL - J ( no new information, see Newsletter #5) 



PASCAL'S (no new information, see Newsletter #5) 



Concurrent PASCAL 



Termination of the Concurrent Pascal Distributic 



August 1976 
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The distribution of the reports and system tapes of Concurrent 
Pascal and Solo was terminated in August when I left Caitech 
to join the University of Southern California. Papers describ- 
ing the language and the operating system have been published 
in the IEEE Transactions on Software Engineering (June 1975) 
and in Software - Practice & Experience (April-June 1976) . The 
tapes are now so wide-spread that they can be obtained elsewhere. 
Several groups are currently moving the system to other computers. 

I will be using Concurrent Pascal at USC, but will not continue 
the distribution of the present system. 

I would appreciate it very much if you would keep me informed 
about your experience in implementing and using Concurrent Pascal. 
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Yours sincerely, 
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Dr. Bruce A. Pumplin 
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The University of Wisconsin-Eau Claire is an Equal Opportunity employer and actively seeks applications from all quaiifi 
persons, whatever their sex, race, color, religion, national origin, or age. 



Per Brinch Hansen 



Computer Science Department 
University of Southern California 
Los Angeles, California 90007 
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Professor Per Brinch Hansen 
Computer Science Department 
University of Southern California 
Los Angeles, California 9000 7 

mNCURR ENT PASCAL DISTRIBUTION _LIST 

Since October 197 5 renorts and system tane 

have heen distributed to 252 institutions' 



8 6 companies 

119 universities 

31 research laboratories 

16 others 

AEG - Telefunken 
Amdahl Corporation 
Analog Technology Corporation 
Basic Timesharing Inc. 
Bell Telephone Laboratories 
Boeing Aerospace Corporation 
Bolt, Beranek & Newman 
Burroughs Corporation 
Comptek Research Inc. 
Computer Automation 
Computer Consoles Inc. 
Computer Sciences Corporation 
Comouter Systems International 
Data General Corporation 
Digital Equipment Corporation 
E. I. duPont de Nemours 
Electromagnetic Systems Laboratories 
First Data Corporation 
Fisher Controls Company 
John Fluke Manufacturing Company 
Foxboro Company ^ 
General Automation Inc. 
General Electric Company 
General Radio Company 
General Research Corporation 
GRI Computer Corporation 
. GTE Laboratories 
Hewlett Packard Corporation. 
Hitachi Research Laboratory 
Honeywell Inc. 
Inco Inc. 

Incoterm Corporation 
•lint-l Corporation 
Interdata Inc. 
Intermetrics Inc. 
International Business Machines 
Arthur D. Little Inc. 
Logisticon Inc. 
Manufacturing Data Systems 
. Media Reactions Inc. 
Metrology Engineering Center 
Mills International 
Mitre Corporation 



Moby data 

National Cash Register 

Nuclear Data Inc. 

Republic Electronics 

Rockwell International 

Sanders Associates 

Softech Inc. 

Sperry Univac 

Squibb & Sons 

System Development Corporation 

Technology Marketing Inc. 

Tektronix Inc. 

Texas Instruments Inc. 

TRW Systems Group 

Varatek Computer Systems Inc. 

Varian Associates 

Wang Laboratories 

Westinghouse Electric Corporation 

Xerox Research Center 

Bell Northern Research (Canada) 

C.C.E.T.T. (France) 

Databank Systems (New Zealand) 

Dynalogic Corporation (Canada) 

EDB-Sentret (Norway) 

Edfor Information Consultants (Canada) 

Electronics Corporation of India 

L.M. Ericsson (Sweden) 

Finning Tractor & Equipment (Canada) 

Ikaslan S.A. (Spain) 

IMAG (France) 

Logica Ltd. (England) 

C. Olivetti (Italy) 

Philips CTI (France) 

Philips (Germany) 

Regnecentralen (Denmark) 

Reuters Ltd. (England) 

Christian Rovsing (Denmark) 

Siemens AG (Germany) 

Softlab (Germany) 

Software Sciences Ltd. (England) 

Systems Designers Ltd. (England) 

Telesincro (Spain) 

Brandeis University 

California Polytechnic State University 

California State University, Northridge 

Carnegie-Mellon University 

Case Western Reserve University 

Clarkson College 

Cornell University 

Duke University Medical Center 

Georgia Institute of Technology 

Harvard University 

Johns Hopkins University 

Kansas State University 

Massachusetts Institute of Technology 

Michigan State University 

Naval Postgraduate School, Monterey 



New York University 
Princeton University- 
Purdue University 
Oral Roberts University 
Sangamon State University 
Stanford University 
Syracuse University 
The College of Wooster, Ohio 
University of Arizona 
University of California, Berkeley 
University of California, Irvine 
University of California, San Diego 
University of Colorado 
University of Delaware 
University of Florida 
University of Iowa 
University of Maryland 
University of Michigan 
University of Minnesota 

University of North Carolina, Chapel Hill 
University of Texas, Austin 
University of Utah 
University of Washington 
University of Wisconsin 
University of Wyoming 
Washington State University 
Washington University, Missouri 
West Coast University 
Western Washington State College 
West Virginia University 

Australian National University 

Bezalel Academy (Israel) 

Carleton University (Canada) 

Chalmers Technological University (Sweden) 

Concordia University (Canada) 

Durham University (England) 

Ecole Polytechnique Federale (Switzerland) 

Eidg. Technische Hochschule (Switzerland) 

Fachhochschule Reutlingen (Germany) 

Simon Fraser University (Canada) 

Imperial College (England) 

Instituto Politecnico Nacional (Mexico) 

Katholieke Universiteit Leuven (Belgium) 

Keio University (Japan) 

Johannes Kepler Universitat (Austria) 

Kyoto University (Japan) 

McGill University (Canada) 

Monash,. University (Australia) 

Neu-Technikum Buchs (Switzerland) 

Politecnico di Milano (Italy) 

Queen's University (Canada) 

Queen's University (Northern Ireland) 

Royal Institute of Technology (Sweden) 

Seikei University (Japan) 

Technical University of Delft (The Netherlands) 

Technical University of Denmark 

Technical University of Eindhoven (The Netherlands) 



-a 

CO 

3> 



m 

GO 

r~ 
m 



m 



en 



3: 



(JO 

en 



en 



en 
oo 



Technische Hogeschool Twente (The Netherlands) 

Technischen Hochschule Munchen (Germany) 

Technische Universitat Berlin (Germany) 

Technische Universitat Wien (Austria) 

Trinity College (Ireland) 

Universidad Politecnica (Spain) 

Universidad Simon Bolivar (Venezuela) 

Universite Catholique de Louvain (Belgium) 

Universite de Montreal (Canada) 

Universite Paris 

University of Aarhus (Denmark) 

University of Adelaide (South Australia) 

University of Alberta (Canada) 

University of Amsterdam (The Netherlands) 

University of Bonn (Germany) 

University of Bradford (England) 

University of British Columbia (Canada) 

University of Brussels (Belgium) 

University of Cape Town (South Africa) 

University of Copenhagen 

University of Dortmund (Germany) 

University of Edinburgh (United Kinqdom) 

University of Glasgow 

University of Hamburg (Germany) 

University of Karlsruhe (Germany) 

University of Kaiserslautern (Germany) 

University of Kiel (Germany) 

University of Manitoba (Canada) 

University of Newcastle upon Tyne (England) 

University of New South Wales (Australia) 

University of Oslo (Norway) 

University of Saskatchewan (Canada) 

University of St. Andrews (Scotland) 

University of Stuttgart (Germany) • 

University of Sydney (Australia) 

University of Tampere (Finland) 

University of Tasmania (Australia) 

University of Tokyo (Japan) 

University of Toronto (Canada) 

University of Tromso (Norway) 

University of Trondheim (Norway) 

University of Warwick (England) 

University of Waterloo (Canada) 

U.S.S.R. Academy of Sciences 

Vrije Universiteit (The Netherlands) 

Electromagnetic Systems Laboratories, Sunnyvale, California 

Jet Propulsion Laboratory 

Los Alamos Scientific Laboratory 

M.I.T. Lincoln Laboratory 

Naval Electronics Laboratory, California 

Naval Research Laboratory, Maryland 

Naval Undersea Center, California 

Naval Underwater Systems Center, Connecticut 

New Mexico Institute of Mining & Technology 

Oregon Museum of Science and Industry 

Pacific Marine Environmental Laboratory, Washington 

Research Triangle Institute, North Carolina 



Michael Reese Hospital, Illinois 

Southwest Regional Laboratorv 

Stanford Artificial Intelliaence Laboratory 

Stanford Linear Accelerator Center 

Stanford Research Institute 

University Hospitals, Cleveland, Ohio 

U.S. Army, Fort Meade, Maryland 

U.S. Army Research Laboratory, Illinois 

USC Information Sciences Institute 

Australian Atomic Energy Commission 

Central Institute for Industrial Research (Norwav) 

CERN (Switzerland) 

Commonwealth Scientific and Industrial Research Oraan (Australia) 

Koninklijke/Shell Laboratorium (The Netherlands) 

National Physical Laboratory (England) 

Norwegian Defense Research Establishment 

Oesterreichische Studiengesellschaft fuer Atomenergie (Austria) 

Max Planck Institut fur Biochemie (Germany) 

Royal Radar Establishment (Enaland) 
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AN AUTOMATIC FORMATTING PROGRAM FOR PASCAL (* received 10 Oct 76 *) 

Jon Hueras and Henry Ledgard 

Dept. of Computer and Information Science 

Univ. of Mass. / Amherst, Ma. 01002 

Imposing formatting restrictions necessarily imposes a burden on a 
programmer, particularly on a student programmer, since he must keypunch or type 
in the entire program himself. It is therefore useful to have a facility for 
taking arbitrarily formatted source code and automatically prettyprinting it. 
However, the design of any such prettyprinter must deal with several serious 
issues. 

Typically, automatic prettyprinters take a heavy hand in formatting a 
program, right down to every last semicolon. Such a scheme either formats 
everything in a rigid fashion, which is bound to be displeasing, or else it 
provides the programmer with a voluminous set of "options". Furthermore, such 
a scheme must do a full syntax analysis on the program, which means that it 
falls prey to the bane of all compilers: error recovery. Thus, before a program 
may be prettyprinted, it must be completely written and debugged. If the 
programmer wishes to prettyprint a program still under development, he is out 
of luck, or else he must do it by hand, in which case he has no need for an 
automatic prettyprinter when he is done. 

We believe that it is not necessary to impose more than a minimum set of 
restrictions, and that any prettyprinter should yield to the programmer's 
discretion beyond this minimum. No matter how many options a prettyprinter has, 
it cannot possibly have one to please everyone in every possible case. We 
further believe that a prettyprinter should not commit itself to a full syntax 
analysis. It should only do prettyprinting on a local basis, dealing with 
individual constructs rather than entire programs. 

In order to demonstrate these assertions, we have designed and implemented, 
in PASCAL, just such a prettyprinter. It is intended mostly as an editing aid, 
and thus does not include most of the "kitchen sink" facilities used by other 
prettyprinters. It simply rearranges the spacing and indentation of certain 
constructs in order to make the logical structure of a program more visually 
apparent. Furthermore, the prettyprinter forces only a minimum amount of 
spacing and indentation where needed. Any* extra spaces or blank lines found in 
the program beyond the minimum required are left there. This leaves the 
programmer a good deal of flexibility to use as he sees fit. 



The prettyprinter that we have implemented is written entirely in standard 
PASCAL (according to the Revised Report in Jensen and Wirth) , and should compile 
and run using any PASCAL compiler that supports this standard. We have compiled 
it using the PASCAL 6000-3.4 compiler from Zurich, and run it in 11K (octal) of 
core on our CDC CYBER 74. The program, as written, is highly modularized and 
table-driven, and is therefore extremely easy to modify and upgrade. 

A copy of the program, with documentation, is available from H. F. Ledgard: 
$7 for a standard 7- track tape or cards, or $2 with a user-supplied tape. 



AMDAHL 470 



(see IBM 360/370 series) 
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TELEPHONE: 692 U22 




BASSER DEPARTMENT OF COMPUTER SCIENCE 

School of Physics (Building A28), 
University of Sydney, N.S.W. 2006 



3rd November,- 19 76 



Timothy Bonham, 

Pascal Implementations, 

University Computer Centre, 

227 Experimental Eng. Building, 

University of Minnesota, 

MINNEAPOLIS. MN 55455 

U.S.A. 



Hello, 



This letter is in response to your inquiry re our 
B1726 Pascal implementation. Unfortunately this project 
was abandoned over a year ago because of lack of time, and 
the (then) continuing lack of suitable documentation from 
Burroughs . 



However, 
implementations . 



I can give you details of other B1726 Pascal 
These are: 



(1) Pascal implemented by Elliott Organick's group 
at the University of Utah. This compiler (and 
interpreter) is based substantially on Brinch 
Hansen's Solo Sequential Pascal compiler (i.e., 
it compiles in lh passes) and we have a copy of 
it. We haven't had much experience with it yet, 
but from what we have seen so far we're not very 
impressed. The compiler appears to be somewhat 
glitchy and unfortunately does not adhere to the 
conventions observed by Burroughs-supplied 
compilers . 

(2) At the European B1700 University Users Meeting on 
July 15-16, 1976, the following projects were 
mentioned: 

(a) University of Zurich (which is not ETH, 
incidentally) are working on 

(i) implementation of a P-code interpreter 
for Pascal. 



(ii) implementation of a Pascal compiler 

to compile down to the SDL S-machine as 
defined by Burroughs. 

The contacts are Mr. P. Schultess for (ii) 
and Mr. K. Hauserman for (i) . 

(b) P. Albrich of the University of Karlsruhe 
(Germany) is implementing Concurrent Pascal. 

Nothing was mentioned about (Sequential) 
Pascal. 

(c) M. Ellison of the University of Newcastle-upon- 
Tyne is implementing "another Pascal Machine 
architecture". He reports that an interpreter 
for this system's machine code has been de- 
bugged and that it is to be benchmarked with 
"Zurich's Pascal-P version 1.0". 

There is to be another European user's meeting ai 
Karlsruhe in February 1977. Our own contact for all the 
European information is through the University of Newcastle- 
upon-Tyne. 

I hope the above information will enable you to obtain 
the material required for the Newsletter. 



en 



Yours sincerely, 
Antony Gerber 
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BURROUGHS B-4700 



William C. Price of Burroughs Co>rporation, 460 Sierra Madre Villa Ave. 
Pasadena, CA 91109, has informed us that he and Robert M. Lansford also of 
Burroughs, 3620 Greenhill Road, Pasadena, CA 91107, are preparing a 
description of their B4700 Pascal implementation. We will print this 
in Newsletter #7. 



BURROUGHS B-5700 (implementations exist) 
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BU RROUGHS B-670Q/B-77QQ 

STATUS HCP'-UJ : roif^n; is ■3^7(3n/lj77i:in PASCAL COMPTLKR 

Thu University of Tusmnnia is developing a compiler far PASCAL to 
produce executable programs on the Burroughs 367Q0/B770Q computer systems. 
The compiler is currently (1976 October) operational but with only a 
simple i/o system (default file declarations and PASCAL 1 i/o statements). 
Current work concentrates on implementing general file and file attribute 
declarations, and on extending i/o statements to a usefully sized set. 

Our current policy is not to release the compiler until it reaches this 
next stable state as otherwise copies of the simplified version mill 
proliferate. Lie would welcome any expressions of interest from B6700 
users in the compiler, and will add addresses to our list of interested 
people, as this will determine the level of support that will be necessary 
to maintain the final system. The anticipated release date is December 
1976. 

Compiler information 

The Burroughs PASCAL compiler is a true compiler for the BS70Q: it generates 
a cade-file which can be executed by the system. The code-file contains 
no BIIMDIIMFO and cannot be bound to. any other language at present (as is the 
case with BASIC). The execution speed and compilation speed of PASCAL 
are comparable to the Algal compiler, though much less code and data space 
is needed for compilation. 

The compiler is based on PASCAL-P, but is written in Burroughs Algol. It 
maintains standard treatment of PASCAL features with the addition of 
B6700-compatible compiler-options and other features. The aim is to 
produce a compiler which will comply with the B6700 conventions as 
embodied in the Algol/FORTRAN/COBQL/etc compilers for that system, and 
for which transferable skills from other Burroughs subsystems can be 
retained. 

Arthur Sale 

Professor of Information Science 

University of Tasmania 

Box 252C G.P.O. 

Hobart, Tasmania 7001 







The University of Tasmania 

Postal Address: Box 252C, G.P.O., Hobart. Tasmania, Australia 7001 
Telephone: 23 0561. Cables 'Tasunt' Telex: 58150 UNTAS 
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FILE NO. . 

IF TELEPHONING OR CALLING 
ASK FOR 
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Pascal Implementations, 

University Computer Center, 

227 Experimental Engineering Building, 

University of Minnesota, 

MINNEAPOLIS , MN 55^55 

USA. 

Dear Timothy Bonham, 

Burroughs B6700 PASCAL Implementation 

1 . Names, etc. of implementors 

Professor A.H.J. Sale (Phone Tasmania (STD 002) 23-0561 Ext. 435) 
Dept. of Information Science 
University of Tasmania 
Box 252C G.P.O. 
Hobart, Tasmania 7001. 

2. Machine tested on 

Burroughs Model III B6700 processor, with vector mode hardware, 196k words 
of main store, disk, k pack drives, etc. Machine operates in university 
environment with heavy interactive use. 

3- Operating System, etc . 

Burroughs MCP Version 11.8 operating system with (few) minor local 

modifications for accounting, etc. Minimal system to operate: not known, 

but unlikely to be any B67OO that small -(store demands are low, little 
else is critical) . 

h. Method of distribution 

Not officially released (December?), nor cost determined. Format will be 
via magnetic tape (both 7"track and 9-track drives available). 

5. Documentation available 

Under development. Will be in form of user manual as well as supplement 
to Pascal User Manual and Report. 

6. Maintenance policy 

To be maintained for teaching use within University as well as larger 
aims. Reported bugs should be fixed as soon as possible, with notification 
to users.. Duration of support not yet determined; several developments 
are also pending. 

7. Standard-compat ibi 1 ity 

Does implement PASCAL in Report with following exceptions where noted 
with reasons: 
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program heading: reserved word program is synonymous with procedure ; 
no parameters (files) are permitted after the program heading. 
Reason: CDC anachronism of no utility in our installation, and 
likely to be confusing. 

set constructor of form A..B not implemented. Reason: future plan. 
FORTRAN control character on print line not implemented. Reason: 

a ridiculous feature to standardize. 
Full Pascal 1/0 not implemented. Reason: future plans, present 

scheme is PASCAL- 1- 1 i ke . 

Extens ions 



Various reserved words, character set transliterations. 
Burroughs comment facility 
ELSE in CASE 

File attributes in declarations 
Format declarations 

Extensive Burroughs-compatible compiler options (Pascal option mode 
not implemented) . 

8. Compiler or interpreter, etc. 

Compi ler : 

generates B6700 code-files which are directly executed by the B6700 

with MCP. There is as yet no BJNDINFO in the codefile so that 
it is not possible to link Pascal to modules compiled by other 
systems, 
written in B6700 Algol entirely. 

Characteristics: 

compiles about 20% slower than FORTRAN or ALGOL, but in about 2/3 of 
their space (for test programs about ^-5k words on average 
instead of 8- 10k). Elapsed compilation times similar, though 
PASCAL slower. Speed should be improved by eventual tuning. 

executes at same speed as FORTRAN and ALGOL (code is very similar and 
optimal) and takes generally longer elapsed residence time 
primarily due to MCP intervention to create new segments for 
record structures (not present in FORTRAN/ALGOL). Elapsed 
residence times about 20% greater than equivalent ALGOL. 

one-pass system: code generated is very close to optimal for B6700 

unless checking requirements of Pascal intervene to inhibit this. 

options include listing of object code in symbolic and/or absolute 
form, editing of input, etc. 

9- Rel iab? 1 ity 

Excellent. Only one system crash during testing attributed to Pascal 
(in run #2) , and a total of two serious bugs uncovered during extensive 
testing. On a machine with minimal protection against aberrant compilers 
as is the B6700, a high level of confidence is essential . The compiler 
code-generator section incorporates many reasonableness checks on the code to 
trap some flaws before they get executed and to aid in tracing errors. 

10. Method of development 

Hand-coded using Pascal-P as a guide/model. All other paths offered 
much greater difficulty on B6700 due to special nature of machine/system. 
Man-month details not kept, and project proceeds in fits and starts as 
teaching intervenes. Project has thus far been limited to two people: 
Prof. A.H.J. Sale and R.A. Freak (support Programmer). 

I trust the above comments meet your need. I enclose a copy of a brief 
technical report on some thoughts on Pascal implementation around August of this 
year. 1 am, and intend to remain, a member of P.U.G. 



^Mu/Qit^ 
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Pascal User's Group 

c/o Andy Mickel 

University Computer Center: 227 ExpEngr 

University of Minnesota 

Minneapolis, MN55455 



m 



Dear Mr. Mickel, 

Until now we have an interpreting PASCAL-System running on the 
B6 700. We got the "PASCAL- Implementation-Kit" with the ? 2 -Compi ler 
(as described in Nori, e.a., "The PASCAL P-Compiler Implementation 
Notes", ETH Zurich) and translated the assembler/interpreter for 
the hypothetical stack computer from PASCAL to Burroughs Extended 
Algol. So we can compile PASCAL-programs by interpreting the 
PASCAL-Compiler and execute the generated Code for the stack 
computer by interpreting it. This technique is very time- and 
space- consuming: The PASCAL-Compiler needs about 30 min B6700 
processor time to compile itself. 

tfe didn't complete the whole bootstrap yet, because of several 
problems concerning the generation of B6 700 machine code in 
general. 
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Sincerely 
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Yours sincerely, 



A.H.J. SALE 



PROF. OF INFORMATION SCIENCE. 



• 75 KARLSRUHE I, jfora 5.11.1976 
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UN1VERSITAT KARLSRUHE 
INSTlTtT FUR INFORM AT1K 



Dip!. Inform. IL Kastens 



University of Minnesota 

University Computer Center 

227 Experimental Engineering Building 

Minneapolis, Minnesota 55455 

c/o Mr. Tim Bonham 

U.S.A. 



Dear Mister Bonham, 

According to your letter dated October 25, 1976, 
directed to Prof. Dr. G. Goos , I will give you some 
information about the state of our PASCAL-acti vi ties . 

We have an i nterpreti ve PASCAL-System running on 
the B 6700. It is based on the PASCAL-P2 compiler and 
the assembler/interpreter from Zurich. We translated the 
Jatter one to a Burroughs Extended Al go! -Program. This 
interpretive version is naturally very time and space 
consuming. (The compiler compiles itself in about 30 
minutes CPU-time.) The system is available on magnetic 
tape for a nominal charge of % 20. oo when tape is supp- 
lied, % 30.oo otherwise. We have a short note for users 
of the svstem (in German only). 

Another project on the B 6700 is based on an early 
version of the PASCAL-JANUS-Compi 1 er (from Boulder, Colo- 
rado). PASCAL is translated via JANUS, STAGE II and an 
assembler to B 6700 "achinecode. We didn't test the 
system enough to say how reliable it is. 

Both projects were not further developed nor main- 
tained because of a lack of manpower at our institute 
and deminished computing capacity on the B 6700. 

Sincerely, 



(U. Kastens) 
Ka/Wh. 



CH 10070 , Iris 50, Iris 80 

Olivier Lecarme of the Universite de Nice, Laboratoire D' Informatique, 
Pare Valrose, 06034 Nice Cedex, France, has helped to clear up our 
confusion about the CI I machines. In a letter of 16 Sep 76, he wrote: 

"Altnough CII 10070 is a nickname for Xerox Sigma 7, the CII Iris 80 
is another machine, more precisely an extension of the first one. Moreover, 
the CII operating system is different from Xerox and transporting a Pascal 
compiler from a Xerox Sigma 7 to a CII Iris 80 probably would not be a 
trivial job. A Pascal compiler for both CII machines has been written by 
Messrs. Thibault and Mancel of IRIA (Research institute in Informatics and 
Automatics, a French government agency), by bootstrapping the first CDC 6000 
compiler. It has now been upgraded to accept Standard Pascal and to allow 
separate compilations, and it is officially distributed by IRIA, a case 
which seems unique. Its overall performance seems to be quite good, and 
it is used in French universities which have one of these machines. 

"The CII Iris 50 is a completely different machine, much smaller, 
and we have some trouble in Nice when trying to implement Pascal. Pascal-P 
works i nterpreti vely, but it is unusable for programs larger than one page, 
and consequently it cannot be used as a tool for bootstrapping a true 
compiler. I plan to write a brief paper for describing the bootstrap 
method which will be used, and which seems to be a unique one. Maybe it 
could be done in time to be included in newsletter number 6." (* perhaps 
Newsletter #7? *) 

CONTROL DATA CYBER 18 (an implementation exists) 

2550 (Control Data supports a cross-compiler on the 

6000/Cyber 70, 170 series) 

3300 (implementations exist) 

3600 (an implementation exists) 

6000/CYBER 70, 170 SERIES (see also Newsletter #5) 

There is very little fresh news on this implementation. It is rumored 
that Zurich has written a first modset ( UPDATE 1) to Release2 of Pascal 6000. 
We at Minnesota have not received it yet. There is a new price list for 
distribution tapes, but no new order form. See Newsletter #5 for the old one. 

If you are in Europe, Asia, or Africa, order from: 



Ch. Jacobi 

Institut fur Informatik 

E.T.Fi-Zentrum 

CH-8092 Zurich 

Switzerland 

(phone: 01/32 62 11) 



The handling charge for Release2 is SFr. 100 
which includes the cost of a mini -tape. 
Do not pay in advance, you will be 
charged at delivery. 



If you are in North or South America, order from: 



George H. Richmond 

Competing Center: 3645 Marine St. 

University of Colorado 

Boulder, CO 80309 

(phone: (303; 492-8131; 



{60 for Release2 tape and documentation. 

$50 if you supply the tape. 

$25 if you have Releasel- you supply 

the tape, and no documentation is 

included. 
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If you are in Australia, New Zealand, or Oceania, order from: 



Carroll Morgan 

Basser Department of Computer Science 

Universtty of Sydney 

Sydney, N.S.W. 2006 

Australia 



CONTROL DATA 7600/Cyber 76 



$A30 for Release2 tape and document. 



Pascal on the CDC 7600 

This Pascal compiler is essentially the Zurich 6000 -3.4 compiler. 
The run-time system is based on that of Hans Joraanstad (see Newletter #4) 
The compiler is release 2. It was developed by cross-compiling from our 
CYBER 72. 

The compiler is currently running under SCOPE 2.1.3 and will re-compile 
itself on a 'half-size* (32K SCM) machine. 

C ompilation S peed 

57000 characters/second approx. Compiler re-compiles in less 
than 10 seconds. 

Execution Speed 

Pascal execution speed has been measured by using the obvious encoding 
in Pascal of Wichmann's Synthetic Benchmark (see Computer Journal Vol.19 No.l). 
The units are in thousands of Whetstones. 



Compiler and 
optimisation 


level 


No runtime 
Check inci 


Array Board 
Check inq 


ALGOL 4 (0=5) 






1996 




1230 


PASCAL 






6850 




6240* 


FTN (0PT=2) 






9345 




3174** 



* Using T + option i.e. all run time checks included 
** forces OPT = 

Maintenance 

The situation is unclear at present. UMRCC will presumably, out 
of self-interest assist with bugs in the 7600 dependent code . The vast 
majority of the compiler and library is standard Zurich code. 

Con tacts 

Mr. H. 0. Ellison or Mr. A. P. Hayes at 

UMRCC, Oxford Road, Manchester M13 9PL, England 



:RAY RESEARCH Cray-1 



IN RKPLY 

REFER TO: C-ll 

MAIL STOP: 296 



UNIVERSITY OF CALIFORNIA 
LOS ALAMOS SCIENTIFIC LABORATORY 

(CONTRACT \\-7405-F\(.-36i 

P.O. BOX 1663 

FOS ALAMOS. SKW MFAK O 87545 



October 27, 1976 



Mr. Andy Mickel 

Pascal User's Group 

University Computer Center 

227 Experimental Engineering Bldg. 

University of Minnesota 

Minneapolis, Minnesota 55455 

Dear Andy: 

I want to tell you about an implementation of Pascal for the Cray 
Research CRAY-1 computer done here at Los Alamos. I will follow the 
checklist outline on page 44 of PASCAL NEWSLETTER #5. 

1. Implementor and maintainor: 

Robert T. Johnson 

C-ll, MS/ 296 

Los Alamos Scientific Laboratory 

P. 0. Box 1663 

Los Alamos, New Mexico 87545 

phone: (505) 667-5014 

2. Machine: Cray Research, Inc., CRAY-1. 

3. Operating System: It was called the Benchmark Operating System, 
and is now called BOS after several extensions and enhancements. 

4. The compiler has not been distributed elsewhere, and no arrange- 
ments have been made for the distribution. 

5. Documentation consists of a two-page description of how to access 
and use the compiler. 

6. Maintenance on this compiler is suspended; the compiler is at 
the end of its usefulness on the CRAY-1, because support for 
it cannot keep up with system development and changes. The 
compiler has been superceded for our development work by a 
cross-compiler for the Model language designed and implemented 
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Mr. Andy Michel 



Oct. 28 



1976 



by James B. Morris, Jr., of this Laboratory. Model was based on 
Pascal and retains many of its concepts. (Cf. "Abstract Data 
Types in the Model Programming Language," Robert T. Johnson and 
James B. Morris, Proceedings of the Conference on Data: Abstraction, 
Definition, and Structure, SIGPLAN Notices, Vol. 8, Number 2, 1976.) 
Pascal-P2 did not seem to provide a good enough basis for further 
work, perhaps P4 will be better. 



7. The compiler implements Pascal-P2 except for I/O. 
no I/O was available on the CRAY system. 



Until recently 



8. It is a cmss -compiler which runs on a Cyber 70 and generates 
CAL (CRAY-1 Assembly Language). The code generation is straight- 
forward and, consequently, the object code quality is low. The 
CRAY-1 requires a more sophisticated code generator to use its 
register resources and instruction overlap capabilities. 

9. The compiler reliability has been good for programs which were 
first tested on the CDC 6000 compiler. 

10. The compiler is a cross-compiler written as a translator of 
P-code output from a (slightly modified) Pascal-P2 compiler. 
Both the Pascal-P2 and the code translator use the CDC 6000 
compiler. About 3 man-months of effort have been expended on 
this development. 

The quality and format of Newsletter #5 were impressive. Keep up the 
good work. 

Sincerely, 

"K >,/ , 'At' ; c.^ 

t /\Y ■' :■ c 

Bob Johnson 



xc: ISD-5 (2) 



DATA GENERAL Nova 800, Nova 1200 , Supernova , Eclipse 

(no reported implementations - we need information) 
DIGITAL EQUIPMENT (DEC) PDP-8 ( an implementation is underway) 



DIGITAL EQUIPMENT (DEC) POP-IP, DECSYSTEM-10 (see also Newsletter #5) 



UNIVERSITAT HAMBURG 



Inrtihrt fflr Informatik 
3 Hamburg 13, SdUttterstraOe 66-72 



INSTITUT FDR 
INFORMATIK 

Prof . dr. h.- 
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_.r. Andy .'lick el 

University Computer Center 

University of : -'in'.:c-sota 

2:k r f Experimental Engineer ;n<; hull Jin;; 

minneapolis , hinnesota 55 ; <^Z 



Ferntprecter: 040 - 41 23 - '! 1 5 1 ) 



B«b6rd«nnetx: 
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Telex-Nr.. 214732 on! hh d 



Datum und Zeidien Ihret Sdbreibent 

Dear mr. nickel, 



Aktenzelchen (beJ Antwort bltte aageben.) 

Na/J-a 



Datsm 

September 2M, 1976 



tne PASCAL Newsletter. huiiiber ? has been studied by me with great 
interest. 

I congratulate Tor the lively exchange of opinions that you enable 
by your effort. I would like to supplement the -two . contributions 
which refer to the DhC3ystem--lG F A3CAL-compiler developped at Kamburg. 

gr. J. UcCool who seems to be utterly disappointed by our compiler 
sent me two letters. The first letter from him(dated "larch 16,76 
arrived here April 9 ,76) presented a program listing with the remark 
that this program started execution and then never could be nudged 
out of the terminal input state - no matter what was typed in. I' 
retyped the program, run it and detected that the initial READLN(TTY) 
h:mi b^en- forgotten. Therefore, the heavily recursive program was 
always one character ahead of what it meant to be. In order to avoid 
any delay .due to the Easter noli days 76 1 wrote him a letter indicat- 
ing the trouble and mailed it personally on Good Friday. A few days 
later (April ^6, 76) I received a letter (dated i -larch 26, 76) from 
';r. McCool complaining of not having.; received an answer to his first 
letter and indicating two additional compiler errors - the date 
error (^-Jan-To) and the fact, that lSC.J on input turned out to be 
~7'}'3]}j99 on output due to the conversion routines, doth letters 
were sent by ordinary nail. Apparently Mr. ilcCool did not realize 
that Hamburg is on this side of the Atlantic and a letter by surface 
mail takes longer to get here then the time after which he shot off 
his second letter complaining about not being '"serviced" properly. 
I mailed a fix for the date error (essentially one instruction needs 
to be added in trie runtime support) within less than a week - and 
that liar, been all I heard from :ir. McCool. 

I n.ention this to indicate, with what expectations one might be con- 
fronted if one provides programs for which not even a nailing charge 
has been asked by me - on the understanding that no regular mainte- 
nance can be given. 

The contribution by Mr. Hedrick shows how the complete availability 
of source code for compiler and runtime support can be used to up- 
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input conversion . 
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~nd I:Ah;,L declaration has been implemented. 
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U!:: core io» ;;taca,, ao,r a;r.l I/.~buffers is allocated. .asre- 
d c^maater action cilonc to specify the amount of cor*- aTt' 
-acaull oe executed after compilation. 
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_ne ne-.v compiler has been fully Intepratau into the PPCP^sto 
ooncjse Command L-npua^e (CCL). The COMPILE, LOAD ana lT^CP- 
communes can be piven topetner wita a larpe number of coi'i-. ?' L^r- 
options m toe standard CCL format. .-----■ 

^f ^ S ! r^ 1 '^:^ 10 ^? 1 : ^ ^?; 1 ^ 61, s ^P^y ^ FP eL If they are 
..n t ,au u^.. d ri,,^.;.) _m_. Oa C;;P% lower case characters ^r- -on- 
veimeu :o uppercase Characters; only the control characters 7-e 
aroapea except l or ^-.n^roec. :■;.-. ich is treated as vpp pr rpi 1 



The problem v ith sinalv accents 

in the^ difficulty to excia.de" run 

usee since tec to noa. oral 

tatior.j restrict Lap the base type to 72 values at the maximum. 

of ChAR i.as seen introduc 
character tet bat a in re 
usee in SIT operations. 



case characters consists 
■;ords are used for set reprosec- 



ute. ; set ranresentations to ::v re then, 
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t ir. runtime error mess apes If it is 
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_ ... . l ^--'^i^d --an be controlled by the usual LIST/ 
i.u^ia sv;itcn in ens compile ccrhiand . 

" Gl,e: -'r^ compiler has seen or.iainaMy develeppea for students. 
-U is_my experience ^ that more trouble results fro;n v:or.-;- 
inp. v;itn outdated, listinps than from creatina a lis tin-- 
file which does not even have to be printed - at jeast^' 
it is available :if the suspicion arises that mai fu-otion 
of tae propraa aiaht be due to typiap errors or incon-" 
sistcat "corrections''. 

The standar, \;ay to supplement COaPILP € 
switches is new available.. 

These errors ars^nov/n to ,;.c and 1 tLoupht they had been fix-c 
i-.:'^ 76 ': 1 ^ 1 distributed July 75. I am sorry for the trouble. 
:' na ' '■'*..• -earica peters :;o as a c-oor desian of pa^^ip^-r -as* J -f 
is sue to the aesire to pass parameters in uo to five realst-rs" 
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*' !^Ja"ir ^-: r r r -; eC! ° V ^ y durins ^^i^l input is quite under- 
"^ cJ * Ga - "™'<*"er, it requires a complete redesign of the (assembly) 



11. GOTO out of p;- jcedure^/f auctions are ih.plai; ented . 

12. The imp lenient at. i oa of formal proceaures/f unctions is adapted to 
the nev: coapiler version fro::: the one introduced at ^echna-che 
hoaeschool Tvavnte s Unscheae/hether land , by a stulent of Dr. C. 
Pron into an eirlier con.pile:' version that he obtained fro.;: 

hamburp. 

13. PACK and UMPACK have been aaapted to the standard definition aiven 
in the PAdCvaL User hanual and Report. Two additional optional ar- 
pui:ieats may be aiven to tiaase procedures indicacina; the lenath 

of the ari'Lj to be packed/unpacked and the starting address in 
t n -."-• r ' a c k e d a r r ? v . 
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Ihe stanoard functions DATP and TI IP are implemented as in PASCAL- 
POOO. : :-'vjo aaditional standard functions CLOCK and TKALTI11E have 
h^en introduced with inteper function value to determine CPU- 
ana Teal-Tine in milliseconds. 

Id. h'ev; standard functions TIPCT and LAS^ have been introduced to 
determine the first snb ]a-st value of a scalar or subrange. 

16. lOWPsPObhj and lirP:vP.>C[J!ID allow to determine the respective index 
values Tor array definitions to enrble an easier chanme of con- 
stant or canpe def initions. 

'. and TAX are available stanoard functions. 
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lo. User- define.: scalar variables can be input and output usirra; the 
Character representation of the value constants. The conversion 
fro-, or to the internal representation is taken care of by the 
runtime support. Values for SET- variables will likewise be con- 
verted on input /output from resp. to the character representation 
as it appears in a source program SHT-constant . 

ly. The introduction of a CALL enables the termination of the current 
PASCAL program and the immediate start of another program. Communi- 
cation between prorpre.ms .is provided by standard D'£C TMPCOR files. 

2C. Procedures are available to determine the value of option switches 
appended to the aXLCdTa command from v.- i thin the PASCAL program. 

21. The PA3DDI: source level debar; system has teen enlarged by an op- 
tional stack and heap dump in source level code. 

22. A P0ST-^0RTTT-TU"T facility at source ianaaap;e level has been ap- 
pended to the PA3D0T system. 

T'3. Runtime checks nave been extended to cover a larger number of pos- 
sible trouble points. IT a prop/ram has been compiled with the 
PASDDT debug option, any runtime error detected - including those 
by the TCPS-10 monitor - vm'll transfer control to the PASDDT-system. 

2k. PASCAL procedures/functions and MACRO-10 routines can be compiled/ 
assembled separately and included together with FORTRAN routines 
into a relocatable object code library. 

25. A machine retrievable manual for this uaCSystem-10 PASCAL imple- 
mentation in Ln-^lish is available. 
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be freely attributed it :r.i.:ht .veil be possible that it is 
in places not known to ,ne . Fro.n the totul hnov,n number of 56 1 have 
to subtract the installation of :ir . bcCool since I assume that they 
discontinued use of our compiler after their bad experiences. Another 
five requests for our compiler iiave arrived in the meantime. 

May I add a last reniirk concerning reports about PACC/bL compiler ex- 
periences: since ail worK done so far seems to proceed on a nonprofit 
basis by voluntary contributions > the feedback of trouble spots to 
people aenei'auin a compiler version is not optimal . One should , 
therefore, encourage one distribution of specific complaints as, e.r,. 3 
those piven by .br . hearick for our compiler version. Any unspecific 
complaint should preferably be returned to the writer v;ith the kindly 
formulated expectation that .,e supports hie claims by at least fyivinr 
details of v;here he encountered trouble, indicatiny the compiler ver- 
sion to vfnich' his renurbu apply ana froi;; v/hon he obtained it. kueh 
an editorial policy nipjit add to the value of the PA.1CAL User uraun 
bev'sletter since - an.orry otner reasons - it m-i^ht laake the user com 
muniny enare of 



DIGITAL EQUIPMENT (DEC) PDP-11 (see also Newsletter #5) 

Stephen C. Schwann of E.I. du Pont de Nemours Co., 101 Beech Street, 
Wilmington, DE 19898, has written us: "I am Chairman of DECUS SIG PASCAL* 
and I will be glad to help with distributing any systems on DEC PDP-lls " 
(* 'maybe Steve can help organize this section of the implementation notes *) 
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To: Persons interested in my PDP-11 

PRSCRL IMPLEMENTATION. 
Oi! • F'RSCRL NEWSLETTER 



bENTLEMEN*. 

This letter is 
trtion fdr t»- 

THIi" LETTER' I " 



trouble not yet 



their installation. 



In 



WORD* My 



TD RI'i,-' ISE YOU OF THE STATUS OF MY PASCAL IMPLEMEN" 
: PTlP-ll. I APOLOGISE FDR SOME DELRY IN WRITING 
■'E BEEN BUSY MOl'ING. 

rOMFILER IS DEFUNCT. 
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sincerely yours , 



MY IMPLEMENTRTIDN MRS NEl'ER MORE THRN R SPARE-TIME PRDJECTJ RND 
PROGRESS WRS SLOW fiS I HA'-'E BEEN l,*ERY BUSY. MY MOl'E TO TORONTO 
ESSENTIALLY ELIMINATES BOTH MY SPARE TIME RND MY CHEAF MACHINE 
ACCESS. fls MY COMPILER NEL-'ER CAME ANYWHERE NEAR OPERATIONAL 
STATUS? RND IT IS MOST UNLIKELY THAT I WILL BE ABLE TO DO MORE 
WORK ON IT ANY TIME SOON? I HRl/E ABANDONED THE PROJECT. 
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Henry Spencer 

Member of Technical Staff 
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Timothy Bomham 
University of Minnesota 



13900 N.W. SCIENCE PARK DRIVE 
PORTLAND, OREGON 97229 
iafeoccjf i03) 641.414! 
HLEX No.3«C;3 



Nov. 2, 1976 



Dear Tim; 

Thanks for your letter. We had noticed the small mention of 
ESI Pascal in the last PUG newsletter and were a little concerned 
because it made reference to the U. of 111 Pascal and implied that 
ours was essentially the same. ESI Pascal was based on the U. of 111 
bootstrap compiler (not the student compiler they are now offering), 
but has been so completely rewritten and reshaped that we have no 
hesitation in claiming it as our own creation. Briefly, our compiler 
runs under RT-11 on any PDP-11 processor in 16K or more and compiles 
full Pascal with a few differences. The enclosed documents will 
explain more. 

Taking your pdints in order: 

1) John Ankcorn did most of the work on the compiler. He and I 
are the Pascalians here and can be reached at this phone. 

2) All 11' s. The compiler source has assembly conditionals to 
shape it for the desired machine. 

3) RT-11, 16K words. We have an RSX-11M version in the works. 

4) see enclosures 

5) Our supplement is enclosed. V/e are working on more. 

6) Probably will be one year of unlimited fixes and updates, 
followed by an annual subscription service. 

7) Basically yes, but see the second page of the supplement. 

8) Compiler (Pascal to Macro assembler text). Fits in 12K 

with the extra space taken by the symbol table. See the enclosures. 
John is preparing a paper describing many of the details. 

9) Excellent. It has been used on our laser trimming systems 
for more than a year, and we have assiduously searched for and 
eliminated bugs. 

10) The compiler is written in Macro-11. We started with the 
U. of 111. bootstrap, changed the syntax scanner, totally changed 
the code generation, wrete our own expression analyzer, and wrote 
our own support package for arithmetic, math and file handling. 
Effort has been on the order of 2 man-years, though some of this 
time was spent on the applications software for our systems. It 
was "the first compiler for each of us, which is why we are grateful 
to the Illini for their initial help. 

I am not sure any of this is directly suitable for publication, 
and I think you should resist the newsletter becoming an advertising 
forum. Nevertheless, we immodestly think that ESI Pascal is probably 
the smallest, fastest, most complete and most reliable compiler for 
the PDP-11, and we are not about to hide our candle under a basket. 
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hl^CTRG-SCIENTIFIC INDUSTRIES OFFERS A COMPLETE 
IMP' Er'ENTATION GF THE PROGRAMMING LANGUAGE PASCAL FOR PDP-11 
COMPUTERS. ALL THE FEATURES OF PASCAL ARE INCLUDED. PLUS 
EXTENSIONS FOR HARDWARE CONTROL. 
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ESI PASCAL COMPILER RUNS ON ANY PDP-11 PROCESSOR 
-11 OPERATING SYSTEM. NO OVERLAYS ARb USED, 

OF MEMORY IS REQUIRED. THE COMPILER USES Thfc 

RECURSIVE DESCENT AND MAKES A SINGLE PASS OVER 
XT AT APPROXIMATELY 3500 CHARACTERS PER SECOND 

TWO FILES ARE PRODUCED; A LISTING OF THE SOURCE 
R0R MESSAGES, AND A TRANSLATION OF THE SOURCE INTO 
LER CODE. THE MACRO CODE IS ASSEMBLED AND LINKED 

MODULE TO PRODUCE THE EXECUTABLE PROGRAM. 
MODULE CONTAINS ALL T H E PRE-DEFINED FUNCTIONS 
ES, PLUS A SIMULATOR FOR THE PDP-11/40 INTEGER 

POINT HARDWARE. TWO VERSIONS OF THE COMPILER ARE 
NE THAT GENERATES PDP 11/^0 FIS INSTRUCTIONS (WHICH IS 
3. 11/04,11/05 AND 11/40 , S) AND A VERSION THAT GENERATES 
NG POINT. THE SUPPORT MODULE CAN BE CONFIGURED 
NLY THE ROUTINES NEEDED BY THE PROGRAM, 
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ALL THE PASCAL DATA TYPES, DATA STRUCTURES AND STATEMENTS 
ESPNT. FORWARD PROCEDURES MAY BE DECLARED. "NEW" AND 
SE M PROCEDURES ARE AVAILABLE FOR THE DYNAMIC 
TI0N OF VARIABLES. PROCEDURES MAY BE DfcCLA.RE 
MPILED AND INSERTED IN THE PROGRAM AT LINK Tl 



ED AS EXTERNAL. 

ME. 



ESPS EXTENSIONS ALLOW VARIABLES TO BE FIXED IN CORE 
AT A CHOSEN ADDRESS, THUS GIVING ACCESS TO THE 
EXTERNAL PAGE I/O ADDRESSES AT THE PASCAL LEVEL. 
ALSO, MACRO CODE CAN 3E INSERTED IN LINE WITH PASCAL CODE. 

BENCHMARKS INDICATE THAT PROGRAMS COMPILED 
BY C SI PASCAL WILL RUN APPROXIMATELY TWICE AS FAST AS SIMILAR 
PROGRAMS COMPILED BY DEC FORTRAN IV, AND MANY TIMES FASTER 
THAN PROGRAMS EXECUTED BY INTERPRETERS LIKE DEC BASIC 

ESI PASCAL HAS BEEN IN USE SINCE IHt SUMMER OF 1975 
IN LASER TRIMMING SYSTEMS 3UILT BY ESI.- IT IS NOW AVAILABLE 
TO ALL PDP-11 USERS. IT IS A SUPERIOR LANGUAGE FOR DATA 
PROCESSING AND EDUCATION, AS EXTENDED BY ESI, IT HAS BECOME 
AN UNEQUALLED TOOL FOR HARDWARE CONTROL APPLICATIONS. 

PRICE OF THE SYSTEM IS $1500. THIS INCLUDES THE COMPILER, 
TH^ SUPPORT MODULE, A CROSS REFERENCE DIRECTORY GENERATOR, 
A SIMPLE TEXT EDITOR AND AN INSTRUCTION MANUAL. 
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ELECTRO-SCIENTIFIC INDUSTRIES 
13900 NW SCIENCE PARK DR 
PORTLAND 0RE ; 97229 

(5J3) 641-4141 



(* David Rowland sent us the machine 
retrievable user manual which accomp- 
anied this page. It is an impressive 
70+ pages long! *) 









FOXBORO Fox-1 



Warren R. Brown of the Foxboro Co., D.330, 38 Neponset Ave., Foxboro 
MA, 02038, phone (617) 543-8750 x2023, has written to us "In response to 
previous inquiries about the FOX-1 implementation of Pascal, we are 
currently formulating a statement for later publication." 



FUJITSU Facom 250-58 
Facom 250-55 



(an implementation exists) 

(an implementation is underway) 



HEWLETT PACKARD hp-2100, hp-5000 



THE UNIVERSH 1 



oANTA Cl.AKA ■ CALIFORNIA • 95053 

TEL: 934 4482 



November 8, 1976 



Mr. Timothy Bonham 

Pascal Implementations 

University Computer Center 

227 Experimental Engineering Building 

University of Minnesota 

Minneapolis, Minnesota 55455 

Dear Mr. Bonham: 

In response to your letter of October 22, I have taken over responsibility 
for Pascal implementation here at Santa Clara from Dan Lewis. There has 
been essentially no progress on implementation since the last contact with 
George Richmond in May of 1975. 

Current plans are to initially implement Pascal via Pascal -P on the University's 
HP3000/Series II, which is running under MPE with 256 K words of memory. A 
very rough completion date is January, 1978 (we hope to beat this, but given 
the realities of implementor time availability, January is as good a guess as 
any). 

Following completion of this task, we intend to implement a (still undefined) 
subset of Pascal for the Department's HP2100, running under DOS III with 32 K 
words of memory. The implementation will be in Pascal and cross -compiled from 
the 3000. 

I'll keep in touch as the implementation progresses. 

Incidentally, I've enclosed my PUG membership- application. 

Sincerely, 

"TT'TV. ~i — — _ 

Ronald L. Danielson 
Assistant Professor 

RID: dim 

End. 



HITACHI Hitac 3800/8700 



(see IBM 360/370 series) 
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^iEYWELL SERIES 6 (an implementation is being considered) 



H315 

A modified Solo (kernel) Concurrent Pascal interpreter is running on the 
Honeywell H316. For more information, write or phone Robert A. Stryk of 
Honeywell Corporate Research, home address: 5441 Halifax Lane, Edina MN 55424, 
office phone: (612) 887-4356. 

6000, LEVEL 66 SERIES (see also Newsletter #5) 



University of Waterloo 



Tfc 



Watnloo, Ontario, Canada 
N2L .JG1 

Matlu'malK «, latully Computing fat tlily 
Dircctoi: .II*) HH r i- 1.211 



August 25, 1976 



Mr. Andy Nickel, Editor 
Pascal Newsletter 
University Computer Center 
227 Experimental Engineering 
University of Minnesota 
Minneapolis, MM 55455 



Dear Sir: 
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Ha ving just read the PASCAL Newsletter Number 4, with its 
list of PASCAL implementations, I thought I should draw to your atten- 
tion the PASCAL implementation for the Honeywell 6000 and Level 66 
Series, machines which we completed for Honeywell earlier this year. 
This compiler, an independent implementation of the full language 
which is not related to any previous PASCAL compiler, has been a com- 
mercial product of Honeywell Information Systems since May 1976 To 
my knowledge, it is the first PASCAL implementation to be officially 
distributed through and maintained by a major manufacturer. 

Yours truly, 



rtr: 



W. Morven Gentleman 
Director 



WMG:cm 

(* note: manuals are available from Honeywell Sales *) 
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SYSTEM 360/370 (this section also includes the Hitachi 8000 series 
anc j t h e Amdahl 470. see also Newsletter #5) 



PAS CAL 8000 Implementation No te 



1. Implementor: 



Machine: 

Operating system: 
Distribution: 
Documentation: 



Maintenance policy: 



November 5, 1976 

Teruo Hikita and Kiyoshi Ishihata 

Department of Information Science 

University of Tokyo 

Tokyo 113 Japan 

phone 03-812-2111 ext 2947 

Hitac 8800/8700 (Hitachi) 

OS 7 

(not yet) 

"PASCAL. 8000 Reference Manual" 
"Bootstrapping PASCAL Using a Trunk" 
(These technical reports are available 
from the Department) 

(not yet decided) 



9. 
10. 



Differences from Standard Pascal: 

Standard, procedures pack and unpack are 

not implemented. 

Files must be declared at main program 

level , 

A few nove] language features are 

included. 

Characteristics of the compiler: 

Written in Pascal (about 5200 source 

lines) . 

Compiler object size is about 100 

kbytes. 

Compiling speed is about. 350 line/sec. 

Execution speed is comparable to 

FORTRAN- compiled objects. 

Reliability of the compiler: Good 



Method of development: 



Modified Nacgeli's trunk compiler and 
bootstrapped it by Pascal-P 
(about three man-months) . 



RIKSHOSPITALETS EDB-AVDEUNG 

UNIVERSITY HOSPITAL, OSLO; COMPUTER DEPARTMENT 



Pilestredet 32 
Oslo 1 , Norway 
Telefon: (02)20 10 50 
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3C-* on our I-." 3 7:"' /Id 
Lrole"nentin.-- kit. 



I believe this implementation differs from other 370-versions 
in two important ways , end therefore it miirht be of interest 

to the ,:i ancal User's Grmp. 
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r'steu, but it is "-airily u?-ec' i r. Grail ins tellation 
/here business-oriented -rocesei r, is do~j natin.- . 
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Our eiv: i s to use Pascal in a oroshjction environment 
whar<s th ?. hul 1 of work is in the file-process in^; field 
i.e. the adnir istrut ice (ecc^o^ic *r.n other) of a 
larye hos^its!!. . 

The onl yr ^ao-yea-Timin^. lan'ui.a^es available are FOPTPAP 
and OPT'Oh, -T.d since we have a ;,ood FORTRAP-milieu, 
F0RT°V T is doi'inatin.;; , even in "oure" f ile-orocessin.'; 
an"."! i cat ions . Naturally '■:<? hone to renlace the. p. (at 
leest aartially) with Pascal. However, in spite of 
all tie virtues of Pascal, it lacks the necess^.r^ 
facilities for our kind of amplications. A number 
of features will have to be added to the lanr,ua : -,e , 
and I will list a few which we consider to be most 
important . 
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To : io the f "' le-;"roev i .ssa r: " you r:us •: : mv-^ ~ j/le-h ana ].in /- 
routiner:;, and since Pascal only :vU')'orrs s< nuptial 
, file-structures , extensions will have to bo aevelo:w^d. 
Weneraliy s^aakin., one arf.ht say that ws have two 
rein 5. r e ra ents : 



to ax- 



il citlv control all t< 



se concur 



stora;e, ?.ika an interface to all available 
acees~-wetuods for data transfer, 

A va.y to. define the Tile end its structure. 

DPS/VS has no "f iie-iaana:,er" where Job-Control-Lansuaye 
m.aa' be use^. to describe the file (record-length, 
'blockin-; '-factor etc.). This forces us either to 
Liake our own f i1.e-i~anayer with a soecial control 
lan"ua';e cr to ™ake ir.odifi cat ions to Pascal's syntax. 

!7 e have chosen the first alternative, not because it 
is the "best" solution, but rather because we want to 
Y.?.e.T> oar version of tn.e lanwuaya connatiblo wita the 
standard. 

External Pro-adures 



cor. 



Ls not only the suoport for separate compilation 
Pascal procedures we consider to be iiwoortant. 
r.ore i r -aortant is the support for the inter- lana 
an, to b« 



..mica 



aba 



to call routines written 



in oth.er lan.;:.ua." e3 , whether they are user-writtr 
amplication routines, library ^ro^raps , sortina,- 
data-base- or* data-oonnunicaticn software. 



ver 



?xree - "f-c^T'.; 

end ; external ; 
? : exrec ; 



Aoyendiny tae naw (reserved) word, external to an ordinary 
record tyr>e definition will' causa all variables of that. 
tv^e to be allocated as separate modules. The nana of 
each nodule is the variable-nawe . This allocation is 
s t at i c , the variable of the example is not allocated on 
the run-time stack, but the scope of the variables the 
procedure where it is declared. it is ^erhans best 
understood by comnarirw, it with ^0?.T.RAP T s nAP^PP 
CO'-llOk (our wain reason fo^ -wanle:aentin : it), or 



a cere, are waat we cons.acer to oe 
wwleincnt, we would very r uch want 
''evilly for usa^s "<'ao (olan to) us 
i-s in;';; aa'PLications , to learn aow t 



The features r. 
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i;w>ortant for 
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cor.wants en f. 




?asoal for fi] 


.e— "arc 


solve siwilar 


or c t 



:urj sinceral- 
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T /saen external procedures are used, the dat 3- trans for 
between then will create problems since ylobal variable 
may not be accessed, ant- since the data-transfer throu.;yi 
parawetres has certain limitations. We have tnarefore 
introduced a new data tyoe-Extcrnal records. 
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SOCORRO, NEW MEXICO 87801 



September 20, 1976 



Mr. Andy Mickel 

University Computer Center: 221 Exp Engr 
University of Minnesota 
iiinneapoJis, Minnesota 55455 

•Dear Andy, 

We have been working on a PASCAL- compiler for the 360/370 series 
for the past year. > The compiler design was done by Dr. Jan V. Gar- 
wick, with implementation by Dr. Garwick, Paul Merillat and myself 
in PL360 and Chris Strachey's GPM. We are about 95% done, and it 
is a full compiler for PASCAL with the following exceptions^ 

1) GOTO's and labels are unsupported (and are flagged with a warning 
-. if used). 

<2) UNPACKED arrays are not supported. 

5) Sets of characters are not allowed. 

4) Tag field specifications in NEW and DISPOSE are ignored, the' 
record is allocated with the maximum space needed. 

*5) Procedure or program segments each must not exceed 4K bytes. 

6) A predefined procedure, CLOSE, has been added to facilitate file 
operations. 

Extensive compile time and runtime error checking is done. The 
runtime checking is optional, and the compiler will generate runtime 
checks by use of a toggle which may be set or reset at any time during 
compilation. There are extensive compile time facilities, including 
a reformatter and cross referencer. 



Andy Mickel 
September 20, 1976 
Page 2 



We have been testing the compiler for about a month now, and 
the results are good. Runtime facilities are still undergoing de- 
bugging, but should be completely done by September 31. We are going 
to use the compiler in our introductory C.S. course, and hope to un- 
earth pathologies that would not come out in use by an experienced 
. PASCALer. 

Mstributim of -an MS version is expected to start by January 
Jst^msA Br. Tsa J&rt&er t>? imr £-5. Jfepariffient -will liandlc inquiries- 

If anybody has any questions about the compiler (other than 
'distributional), I would be glad to answer them. 

We think the PASCAL newsletter is great, keep up the good work. 

SincpfejyA 







Robert Knight, Director 
Office of User Services 
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STONY BROOK's PASCAL/360 - A STATUS REPORT - NOVEMBER 1976 



The Stony Brook Pascal Compiler for IBM 360 and 370 computers 
is alive and well, As of November, 1976 more than 65 copies have been 
issued, and several installations are using the compiler under a live 
load. The compiler project continues at Stony Brook, and a second 
release is planned for January, 1977. 

Release 1 was issued in June, 1976. It provides an almost com- 
plete implementation of Standard Pascal except for a variation in the 
means of specifying print field widths in the Write procedure. Not 

. implemented in Release 1 are nonstandard ... files, . : and the standard pro- 
cedure Dispose. The compiler has been successfully installed under the 

.OS/MVT, MFT, VS1 and VS2 operating systems, and, under VM/CMS with mod- 
ifications to the OS interface. A DOS interface is nearing completion. 
At present, the main storage requirement is 160K. bytes including space 
•for file buffers. • . ' •' \- . -..' - : ; ; , ■:;,„, - ■■■-■ 

The compiler is coded in XPL;, with an assembler-coded monitor 
that provides the interface with OS. We do not have good statistics on 
compilation speed, but Release 1 has 1.93 CPU-second overhead to compile 
a trivial program on a 360/65. This is believed to be mainly due to the 
complexity of opening and closing files under OS/360. 

The execution time of several compiled Pascal programs has been 
.compared with that of equivalent translation into ALGOLW, whose compiler 
..is known to produce good, though not -optimized code. : - The Pascal programs 
r execute faster, in nearly all, cases. „,- . . .: ... ;;.-.■•■•'. 

Although it would be foolhardy to. allege that a compiler that has 
been field-tested for less than six-months is bug-free, we believe that 
the majority of errors have probably been corrected. The three updates 
have repaired all errors reported as of November 1, 1976, as well as 
: improving the resiliance of the compiler in the presence of Pascal source 
program errors, and reducing the storage requirements from 180 to 160K 
bytes. Updates are issued In the form of source-language (.XPL or BAL) 
patches to be input to a card-oriented editor. Both the editor and an 
XPL compiler are furnished on the distribution tape. 

Present work is directed toward completing the implementation of 
nonstandard files, management of heap storage, and external compilation, 
all of which will be included in Release 2. This release, subject to 
later updates to correct errors and improve performance, will be the 
production version of the compiler. 

Future work will be directed toward producing an edition special- 
ized for student use. This will offer the same capabilities in a compile- 
. and-go version, except for a limitation on the size of programs that can 



be compiled. The design target on the main storage requirement is 120K 
bytes. Compilation speed will be improved, primarily through the use 
of corefiles and interpass data communication buffers to reduce I/O. 
The compiler already includes excellent syntax error recovery, intelli- 
gible error messages and runtime diagnostics that enhance its usefullness 
in education. 

For those interested in acquiring the Pascal/360 compiler, the 
cost is $175.00, which includes distribution, complete system documenta- 
tion (when available), and maintenance at least through August, 1977. 

A 50-page User's guide is available at a cost of $1,00 per copy 
in quantities of a dozen or more. The User's Guide is intended as ' a 
supplement to Jensen and Wirth, and tells everything that' a user needs 
to know about the compiler. 

At no cost whatsoever, one can obtain a packet giving additional 
information on the Pascal/360 compiler by sending a request to: 



Pascal Compiler Project 
Department of Computer Science 
SUNY at Stony Brook 
Stony Brook, New York 11794 
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17 September 1976 



UNIVERSITY OF MINNESOTA 

TWIN CITIES 



GO 



University Computer Center 

227 Experimental Engineering Building 

Minneapolis, Minnesota 55455 

(6i2)37»ssa: 6-7290 



Andy Mickel 
PASCAL User's Group 
University Computer Center 
227 Experimental Engineering 
University of Minnesota 
Minneapolis, MN 55455 



Dear Andy, 



I was quite surprised to see my last letter to you printed 
in the Newsletter. Nevertheless, since it did appear, I feel 
compelled to follow up on my comments about the Stony Brook PASCAL 
compiler for the IBM S/370. 

At the time I wrote the letter, the compiler was, indeed, buggy. 
However, response from them has been excellent. I have since received 
and installed two updates; the cover letter with the second stated 
that it fixed all reported bugs. I have since run at least one 
medium-to-large (700 statements) program using it, with no trouble. 
And the post-mortem histogram — showing how many times each statement 
was executed — is a most useful feature. 

Complaints about the compiler? Sure, there's always something 
that could be improved. The compiler is a bit too big (180K) , and 
a bit too slow for small programs (high fixed overhead per compilation) , 
and, perhaps most serious, they omitted the standard formatted-write 
notation. And it would be nice if the compiler wrote out standard 
OS-format object modules. 

I should note that I ordered the Stony Brook compiler in 
preference to the Manitoba version, since it seems more suited to 
use with production-quality programs. Particularly serious restrictions 
(from my point of view) in the Manitoba compiler are its lack of I/O, 
its lack of a full version of NEW, and its restriction on the size of 
procedures (4K). /l 

/ 



September 2b 9 1976 

Dear Steve, 

I felt a twinge even as I was putting your letter into the last 
newsletter* I feel that the interest that other persons has/ in your opinions 
outweighed the fact that I gave you no warning that it would be printed* I'm 
glad you wrote a follow up letter and sent a copy of it to SUNY Stony Brook, 
And I'm glad that their compiler is working better, also. Funny, we struggle 
so hard just to get tidbits of information. 

As I guess you can tell from Newsletter #5e w ® are trying to push hard to 
repair the confusion about lascal Implementations, 

So, thank you very much for writing. I'll of course print your letter 
in Newsletter #6. 

Sincerely, 
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-Steve Bellovin 
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cc: William Barabash, SUNY at Stony Brook 
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insfcstufc de recherche economique at" dF2 pJanification 



DEPARTEMENT 

INFORMATIQUE 

Telephone : 87.99.61 
poste 492 



v/ref. 

n/ref. jpp/MHV 



Pascal User's Group 
C/0 Andy Mi eke I 

University Computer Center 
227 Exp Engr 
University of Minnesota 

Minneapo! is, MN 55455 

Saint-Martin-d'Heres le 4 Novembre 1976 



Monsieur, 

En reponse a votre lettre du 25 Ocotbre 1976 voici le point des travaux 
faits sur le compi lateur Pascal. 

- 11 est operationnel sur 

•360/67 avec OS/MVT 
3/0/ 148 ave. Vb/MHT 

- Demande REGION 220 K pour s'autocomp 1 ler. 

- Distribution sur bandes macnetiques 9 pistes/800 bpl . 

- II existe un supplement au manuel du langage Pascal, decrivant ]' imple- 
mentation sur IBM. 

- Langage Pascal accepte est conformo au standard 74 a queiques exceptions 
pres. 

II manque Road/Write ma is I ' i nsta l I at ion est provue pour la fin 1976, 

- Ameliorations successives sont obtenues par compilation, 

- La vitesse d'executlon moyenne est : 

. compi lateur standard 

6000 lignes sources _ 105 secondes CPU 
360/67 ) . compi lateur "dope" 

6000 lignes sources _ 84 secondes CPU 



CO 



- Ajouts non standards : 

. Cf. manuel specification 360 
. procedures assembleur. 

- Le compi lateur Pascal a aussi ete i nsta lie en CP/CMS. 

Je vous prie d'agreer, Monsieur, 1 Expression de mes sentiments 
distingues. 
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Olivier Lecarme of the Universite de Nice, Laboratoire D' Informatique, 
Pare Valrose, 06034 Nice Cedex, wrote us in a letter of 16 Sep 76: 

"A Pascal compiler for the IBM 360, which was probably the first one, 
has been done in one of the Universities of Grenoble. Unfortunately, the 
people who made it had no time nor support for distributing it, although 
it seems to have impressive performances in execution time (but less good 
in storage needed for compilation). People to contact are Messrs. Henneron 
and Tassart (Informatique & Mathematiques Appliquees, B.P. 53, 38041 
Grenoble-Cedex, France." 
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IBM 1130 

Olivier Lecarme of the Universite de Nice, Laboratoire D' Informatique, 
Pare Valrose, 06034 Nice Cedex, in his letter of 16 Sep 76: 

"Implementations for Pascal-P, Pascal-S and finally full Pascal have 
been done for the IBM 1130 and are in use at the University of Neuchatel 
(Centre de Calcul, Chantemerle 20, CH-2000 Neuchatel, Switzerland)." 
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ICL 1900 



(an implementation exists) 



2970 ( an implementation is underway) 



INTEL 8080 



(we need more implementation information) 



MOTOROLA 6800 



4 Nov 
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INTERDATA 7/16 



Rod Steel of Tektronix, Inc., MS 60-456, P.O. box 500, Beaverton, OR 97707 
reported: "If we can find the resources, we may bring up a P-compiler on the 
Interdata 7/16 at TEK." 

Michael S. Ball of the Naval Undersea Center, San Diego, CA 92132, wrote 
in his report on the Univac 1100 implementation that the Center has cross 
compilers, running on a Univac 1110 and generating machine code for the 
Interdata 7/16, for both Concurrent Pascal and Sequential Pascal. See his 
report for more information. 



INTERDATA 70 ( no known implementations) 



MI CR0DATA 800 (no known implementations) 



MITSUBISHI MELCOM 7700 (an implementation exists) 



PASCAL Implementations 
University Computer Center 
227 Experimental Engineering 
University of Minnesota 
Mi nne ap o 1 i ~ , J IN 5 5 4 5 5 

Gentlemen: 

This letter is in response to your letter dated October 25 in 
which you requested PASCAL implementation information. Fo] low* ng 
are my responses to each of your ten points. 

1. Implement or, maintainer: 
Before Nov, 26: Mark D. Rust ad 

Moorhead State University 

Computer Center 

1J04 7th Ave. s. 

Moorhead, MN 5 ft 5 60 
After Nov. 26: Mark P. Rue tad 

585 Harriet Ave. 

Apt. £215 

St. Paul, MN 55112 
As yet there is rn distributer. 

2. The implementation is specifically designed for the 
Motorola 6800 -based HITS Altair 6S0b, but can easily be 
transported to any 3-bit machine (the Zilog Z-80 would 
be highly recommended) . 

5. Since implementation is rut complete, precise information 
is not yet available, however, the compiler will definitely 
run on an 8-bit microprocessor with 52K bytes, a TTY and 
no disk capability. It is likely that the memory requirement 
will be somewhat under 32K. 

4. No distribution since implementation is not complete. 

5. No documentation available yet. 
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6. This compiler is, more or less, my hobby so a 
maintence policy cannot be stated. 
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This implementation is of a subset of PASCAL which I cali 
PASCAL- M (PASCAL for microprocessors). Due to the very 
limited resources of microprocessors, PASCAL-M does not 
include the following PASCAL features: 

a. no files - all I/O via READ, WRITE 

b. no REAL type 

iio declared scalar types 

d. no variant records 

e. no LABEL section 

f. no GOTO statement 

g. no WITH statement 
no FOR statement (use MULE instead!) 
no CASE statement (may be pur back in) 
no run- time checks yet 

standard procedures are: READ, WRITE, NEW, RELEASE, 
READLN, WRITELN, ORD, CHR, EOLN, MARK 

It is possible that the final implementation will' have the 
CASE statement reinstated and that I may produce additional 
implementations for those having more resources to include 
REAL and FILE types. 

The compiler produces an intrepretive code which is output 
onto an external medium such as paper tape which is then 
loaded with the intrepreter for execution. The compiler 
is written in the subset of PASCAL which it compiles and 
is about 2200 lines of code. The compiler should compile 
useable programs in under 32K bytes. The compilation and 
execution speeds can not yet be tested. 

The reliability of the compiler seems to be excellent. 



NCR CENTURY 100, 200, 300 (no known implementations) 



PHILLIPS P-1400 ( a non-standard implementation exists) 



PRIME P-400 



Phillip H. Enslow of the School of Information and Computer Science, 
Georgia Tech, Atlanta, GA 30332, has informed us that Georgia Tech is boot- 
strapping a compiler for the Prime P-400 using Pascal-P4. The P-400 is a 
large "mini" with a 32 bit word, and 512 million words of hardware supported 
virtual memory for each of 64 possible users. 



SEL 8600 (an implementation exists) 



SIEMENS 4004/157 

H.-J. Hoffmann of the Fachbereich Informatik, Techn. Hochschule, 
Steubenplatz 12, D-6100 Darmstadt, Germany, wrote us: "We have implemented 
PASCAL P2 in three different versions (fully interpretive, SC-code auto- 
matically translated to assembly language, code emitters for assembly language) 
for SIEMENS 4004/157 computer. Usage in some systems programming work." 

TELEFUNKEN TR-440 (an implementation exists) 
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10. PASCAL-M was developed from PASCAL-P2 and is being cross- 
compiled by Mike Ball's IINIVAC 1100 PASCAL. I would 
estimate that about two man-months have gone into this 
implementation and I expect that about one more man-month 
to complete it. I have found the PASCAL compiler much 
easier to work on and understand than I expected and I 
believe that this is attributable to the language it is 
written in (PASCAL) . 



TEXAS INSTRUMENTS TI-ASC (an implementation exists) 
TI"980.A (implementations exist) 






I will be preparing both documentation and reports on this 
implementation of PASCAL for publication once implementation is 
completed. For your information, all that remains is to debug the 
M-CODE (what I call my interpretive code, like P-CODE) interpreter. 



Sincerely, 
Mark Rust ad 
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UN I VAC 1100 series 



NAVAL UNDERSEA CENTER 
San Diego, California 92132 



2 November 1976 



Mr„ Andy Mickel 
University Computer Center 
227 Exp Engr 
University of Minnesota 
Minneapolis, MN 55455 

Dear Mr,, Mickel: 

Thank you for the Pascal newsletter., I just got number 5 and enjoyed it greatly 

As you know, we have a quite complete implementation of Pascal for the Univac 
1100 series. I have enclosed some performance data on the compiler and generated 
code which you may find of interest t . We kept the implementation as close as 
possible to standard pascal, with extensions only to allow interface to the 
Univac Exec, and for compatibility with other systems whose code we wanted to 
use. The restrictions are essentially the same as those in the CDC compiler. 
We have been using the Pascal compiler for about nine months, and its reliability 
has been quite good. It should soon approach excellent. 

We are using the compiler for general purpose programming and "systems" programming 
for the Univac and other machines., Its usage is steadily increasing, and is 
currently about 60 to 70 compilations a day.. This compares to Fortran which 
is about 600, but of course, each Fortran subroutine is counted separately. User 
response has been quite favorable, and the interface to the user is at least as 
good as the rest of the language processors available for the 110 series. A 
large, but unknown, percentage of the use is interactive (demand mode in Univac 
terms). 

One major use of the system has been the development of compilers for Concurrent 
Pascal and Sequential Pascal for an Interdata 7/16. These compilers are based 
on those supplied by Per Brinch Hansen, and generate machine code for the 7/16. 
They are currently operating as cross compilers, running on the Univac 1110 and 
generating code for the Interdata. We are currently in the process of moving 
them to the Interdata for self-compilation,, The project has been a very 
interesting exercise in machine independence, and the code which must be changed 
when moving the compilers from the Univac 1110, a 36 bit l's complement machine, 
is surprisingly small. We have not measured it accurately, but it is on the 
order of one to two percent 

These compilers are highly optimizing compilers, and the direct machine code 
which they generate is up to twenty percent smaller than the interpretive version 
generated by the original compilers. Since there. was no attempt to make the 
interpretive code compact, this is not surprising. The next project along these 
lines is to modify the compiler to generate code for the Interdata 8/32., 

One problem which we have is keeping up to date on various extensions and changes 
to the CDC compilers. As you mentioned in the newsletter, this compiler has 
served as an unofficial, standard for compatibility, and we would like to know 
about things like the "VALUE" section before we see them in some code from another 



installation. Perhaps this data could be published in the newsletter as it 
becomes available? Since we are promoting the language as leading to portability, 
we should practice what we preach. 

Finally, where can I obtain copies of the new documents from Wirth's group. I 
am particularly interested in the paper on Pascal-S. 

Sincerely, 



r^-^ 



Michael S. Ball 



PERFORMANCE OF THE PASCAL 1100 SYSTEM 



14 October 1976 



The following performance was measured on a Univac 1110. All times given 
are totals, including both CAU time and CCER time. 

1. Compiler Performance . 

The compiler performance was measured as it compiled itself. The 
compiler is 7,494 lines of code, including comments and blank lines. It 
compiles into 34,875 words of code and literals. The library adds 5,912 
words (including some data area) , for a total of 40,787 words. The Univac 
compiler interface routines account for 4,685 words of the library. The 
data space allocated for the compiler is 16,108 words, and while compiling 
itself the compiler uses 8,068 words in the heap and 7,444 words in the 
stack. 

The compilation rate is 105 lines per second with an output listing, 
and 118 lines per second without a listing. 

^ • Compiled Code Performance . 

The compiled code was compared with that generated by the NU7\LG and 
ASCII FORTRAN processors. For both Pascal and NUALG, tests were done both 
with and without run-time checks. The FORTRAN compiler never generates 
run-time checks, but does allow for three different levels of optimization. 
The normal mode provides no optimization, and optional modes provide local 
and global optimizations. The local optimization mode was chosen as the 
standard of comparison, since the short test programs which were used 
provide an unusually simple case for the global optimizer, and allow it to 
perform much better than would be expected for the average program. 

The programs used as a basis for comparison were taken from Wirth's 
paper on the design of a Pascal Compiler. 'They are all programs which are 
easily written in all three languages, and so do not use the expressive 
power of Pascal. In addition, the time taken to call a simple procedure 
with four value parameters were measured for each processor. The results 
are summarized in the following tables. 
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Time 
Rel 



2G.4 
1.21 



108.6 
4.96 



21.9 
1.00 



VARIAN 520 
V73 



(no known implementations) 
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Table 1. Procedure Call Times. 



PART 

PARTNP 

SORT 

MATMUL 

COUNT 



PART 

P'ARTNP 

SORT 

MATMUL 

COUNT 



PASCAL 

Time Rel 

9.36 0.62 

1.10 1.18 

24.61 1.37 

18.70 1.82 

4.99 0.30 



Time 
15.10 
0.87 
18.01 
10.27 
16.88 



Rel . Time 

l.C 15.10 

0.94 0.93 

1.00 18.01 

1.00 10.26 

1.00 16.83 



PASCAL 
NO CHECKS 
Time Rel 

9.17 0.61 

0.99 1.06 

20.22 1.12 

14.69 1.43 

4.69 0.28 

FORTRAN 
LOCAL OPT . 
Rel 



NUALG 

NOALG NO CHECKS 

Time Rel Time Rel 

12.88 0.85 12.67 0.84 

3.06 3.29 2.95 3.17 

32.92 1.83 26.81 1.49 

21.02 2.05 17.46 ' 1.70 

12.15 0.72 11.13 0.66 

FORTRAN 

GLOEAL OPT. 

Time Rel 



14.94 0.99 



0.79 



0.85 



1.00 
1.00 
1.00 
1.00 

1.00 16.40 0.97 
Table 2. 



10.56 ' 0.59 
4.04 G.39 



The program listed on the left side of Table 2 are: 

PART compute the additive partitions of a number (30 in this case) and 

print the results. This uses recursion for Pascal and NUALG, and a 
hand simulated stack for FORTRAN. 

PARTNP the same as above, but with no printing 

SORT sort an array of 1,000 numbers by a bubble sort 

MATMUL matrix multiply of two 100 by 100 matrices 

COUNT count the characters in a file and print the number of times each 
occurs. The file was 124,000 characters long. 



M. S- BALL 



California State University, Chico 

Chico, California 95929 



Department of Computer Science 
(916)895-6442 



November 2, 1976 



Mr. Timothy Bonham 

Pascal Implementations 

University Computer Center 

227 Experimental Engineering Building 

University of Minnesota 

Minneapolis, MN 55455 

Dear Mr. Bonham: 

Thank you for your interest in our activities at 
California State University, Chico. 

Due to some staff changes, our Pascal project has 
not been completed. The implementation is planned on 
a Varian V7 3. Pending the completion of hardware 
changes, this project will remain stagnant for at least 
another year. 



Sincerely, 



\ 



Orlando S .•' .Madrigal , Ph . D . 
Chairman & -'Professor 
Department of Computer Science 



OSM:lt 



XEROX Sigma 6, Sigma 7, Sigma. 9 (see also en 10070) 

Olivier Lecarme, Universite de Nice, Laboratoire D' Informatique, 
Pare Valrose, 06034 Nice Cedex, France, in his letter of 16 Sep 76: 

"A complete and standard compiler for the Xerox Sigma 6,7 and 9 has 
been done by Pierre Desjardins, who can give you all desirable information. 
Anyway, it seems to be a yery good implementation, especially in the domain 
of compatibility and conformity to the standard." 

(* We do not have Pierre Dejardins 's correct address, can someone help? 
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pascal user's group ALL PURPOSE COUPON 

USER'S *#####*•#***•######* 

GROUP 

Clip, photocopy, or reproduce, etc- and mail to: Pascal User's Group 

c/o Andy Mickel 
University Computer Center 
227 Exp Engr 
University of Minnesota 
Minneapolis, MN 55455 

(phone: (612) 376-7290) 

/ / Please ™*< ^ ^^J/nf the PASCAL USER ' 5 Gm? for the rll^L Academic 
enter me as a member of current 

Year ending June 30. I shall receive all 4 issues of VoaqjiI U&teloXtoji for 

the year. Enclosed please find $4.00. (*When joining from overseas, check 

the NwAleJXQJi POLICY section for a PUG "regional representative".*) 

/ / Please send a copy of Pascal Uoml&ttoA Number . Enclosed please find 

$1.00 for each. (*See the Hm&l&ttoJi POLICY section for issues out of print.*) 

/ / My new address is printed below. Please use it from now on. I'll enclose an 
old mailing label if I can find one. 

/ / You messed up my address. See below. 

/ / Enclosed are some bugs I would like to report to the maintainer of the 

version of Pascal. Please forward it to the 

appropriate person so that something can be done about it. 

/ / Enclosed please find a contribution (such as what we are doing with Pascal 
at our computer installation), idea, article, or opinion which I wish to 
submit for publication in the next issue of VaAzal Hm hloXtojt. 

I I None of the above. _____ _ ___ ___' 



Other comments: From: name 

address 



phone 
date 



(*Your phone number helps facilitate communication with other PUG members.*) 



return to: 

University Computer Center 
University of Minnesota 
227 Experimental Engineering Building 
Minneapolis, Minnesota 55455 USA 

return postage guaranteed 



